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The Naval Facilities Engineering Command utilizes 
several automated systems in carrying out its mission. These 
systems are presently geared toward the Headquarters and 
major Command levels cf management and not toward the field 
activities and smaller offices. This thesis examines an 
Architect-Engineer type contracting management procedure and 
proposes an automated alternative of the contract adminis- 
tration process using micro-computer technology for field 
activities. A brief examination is made of the NAVFAC auto- 
mated systems and of the structure of the NAVFAC contracting 
organization prior to the presentation of a proposed A-E 
Management Information System. The closing chapters discuss 
integration of the proposed system, automated tools which 
make the system possible and the interface designs utilized 
to make the system user friendly. 
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I. I NTR ODUCTION 



A. OVERVIEW 

The Naval Facilities Engineering Command has the mission 
within the Navy of the plant management of naval shore 
facilities. The support structure for the organization is 
comprised of upper level program managers, geographically 
located design divisions, intermediate contracting offices 
and activity level monitoring staffs. One major management 
function of NAVFAC contracting is for Architect-Engineering 
services, maintenance services and construction. This func- 
tion, as well as the other NAVFAC functions, is supported 
through an automated management system which has grown from 
a mechanized accounting system in the late 1940’s to a 
guasi-distributed automated system. To a limited extent, the 
functional distribution of the system has reached some 
Engineering Field Divisions and is beginning to reach sere 
field activities. This thesis will explore the possiblity 
of automating the field activity functions concerned with 
the Architect-Engineering contract process. 

The following is an overview of the thesis chapters: 

Ch apt er II. - Naval Facilities Engineering Command 

The overall mission of the command and in particular 
the contracting aspect are discussed. 

Cha pt er III . - Naval Facilities System (NFS) 

The automated management system is discussed. The 
major components which constitute the NAVFAC informa- 
tion system are described along with a discussion of 
the advantages and benefits of evolving from a file 
oriented structure to a generalized Data Base 
Management Sjstem. The Naval Facilities Systems 
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Office is described and its changing role in the NFS 
is discussed. 

Chapter IV. - The A-E Contracting Process 

A brief description os given of the steps required by 
the contract administration staff to put an A-E 
contract through the three phases of the A-E 

contracting life-cycle, pre-negotiation, negotiation, 
and post-award phases. 

Chap te r V. - Requirements Determination 

The automated support needed by the field activities 
to adequately use the data collected for the NFS is 
identified. Tools are described which could be used 
to build a proposed management information system for 
the A-E contracting environment. 

Ch ap ter VI. - Automation of the Pre-Negotiation Phase 
Discussion of a proposed management information 

system for the A-E contract administration process 
begins in this chapter and concludes in chapter 8. 
The Pre-Negotiation steps are discussed in the auto- 
mated environment. Means an'd methods of automating 
the process are investigated. The major concepts 
involved are the use of databases, report/letter 
files and application modules to drive the entire 
contracting administration process. 

C hapte r VII . - Automation of the Negotiation Phase 

A similar approach is taken as described in 
Chapter 6. 

C ha p ter VII I ♦ - Automation of the Post-Award Phase 

A similar approach is taken as described in 
Chapter 6. 

C ha pter IX. - End-Oser Interface 

Considerations of the users of the automated systems 
in terms of the best interface design are discussed. 
Also discussed are the factors that affect the 



end-user’s perception of the system and various 
screen design methodologies. Samples of recommended 
screen designs are presented. 

Chapter X. - System Integration 

An overall view of the proposed automated A-E 
contracting system is presented along with a review 
of the automated tools which comprise the subsystems 
of the MIS for the A-E process. The chapter concludes 
with a discussion of how the field office could best 
utilize an automated system to meet NFS requirements 
as well as satisfy local management needs. 

Chapter XI. - Conclusions and Recommendations 

General conclusions and recommendations for 
implementation of the system in the field are 
discussed. 



B. GCALS AND OBJECTIVES 

The objectives of this thesis are threefold. The author 
focuses on the management process of the NAVFAC Contracting 
Organization and how this process affects the field Public 
Works Officer, the Officer In Charge of Construction, and 
the Resident Officer In Charge of Construction. This will 
satisfy the objective of the author to become acquainted 
with the Navy Facilities System Plan [Ref. 1], Second, a 
sample module of a proposed automated tracking and reporting 
management system for A-E contracting is presented through 
the application of a database management system. This 
permits the investigation of the possible uses of a micro- 
computer database management system in a field, non- 
programming, professional environment. The third objective 
is to investigate the possibility of developing a 
user-friendly interface between a complex micro-computer 
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database system and the novice user. If such 
possible, the application of micro-computer 
management systems can be expanded. 



a interface is 
based database 
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II. NAVAL FACILITIES ENGINEERING COMMAND 
A. NAVFAC CONTRACTING 

The Naval Facilities Engineering Command (NAVFACENGCCM) 
is responsible for and authorized to perform the design, 
planning, development, procurement, cons tr uction, altera- 
tion, repair and maintenance at all shore activities cf the 
Naval Establishment for public works and public utilities 
[Ref. 2; p.1.3.1]. This responsibility is assigned by the 

Secretary of the Navy through the Chief of Naval Materiel. 

The specific functions performed under this authority 
are as fellows: 

a. Approving the selection and compensation of an 
architect or engineer; 

b. Approving the selection and fee of a general building 
contractor; 

c. Consent to the placement of any subcontract for civil 
works; 

d. Approving any plans or specifications; 

e . Approving of major alterations or increased costs 
within the estimated cost set forth in a contract for 
civil works; 

f. Inspection, supervision, and administration cf the 
terms of subcontract and acceptance of performance; 

g. Monitoring compliance with labor standards 
requirements; 

h. Ordering or approving changes relating tc civil 
werks; 

i. Cognizance of all matters relating to the acquisition 
of real property. [Ref. 3] 
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In essence, NAVFAC is responsible for any construction 
related activities from cradle to grave throughout the Naval 
Shore Establishment. This thesis will primarily focus on 
the first function mentioned above, Architect-Engineering 
contracts. These contracting services are utilized by the 
NAVFAC organization to augment in-house planning and design 
capability. Architect-Engineering contracts (hereafter 
referred to as A-E contracts) are used primarily to procure 
design drawings and specif ications for contemplated 
construction or maintenance and repair projects. A-E 
contracts can also be utilized as a means: 1) to providing 
consultation to contract administrators during construction 
projects; 2) to incorporate specialized review and checking 
of accuracy of contractor’s drawing, material lists, or 
equipment performance data; 3) to prepare record drawings or 
update master drawings and plans; and 4) to acquire inspec- 
tion services for construction work in instances where 
in-house expertise is non-existent or not available. 

B.‘ NAVFAC CONTRACTING ORGANIZATION 

The sole "Contracting Officer" within NAVFAC is the 
Commander, NAVFACENGCCM . All ether persons exercising NAVFAC 
contracting authority act and sign in the stead of the 
Commander. The NAVFAC Contract Organization is shown below 
in Figure 2.1. 

The primary players in the contracting chain are the 
Commander NAVFAC, Engineering Field Divisions (EFB) , 
Of f icers-In-Charge- cf-Constr uction (OICC) , and the Resident 
Of f icers-In-Char ge- cf-Construction. As can be seen in 
Figure 2.1, the Coriander NAVFAC sits at the head of the 
organization where all final contracting decisions reside. 



15 



r 






+ 

| CDR 



NAVFAC | 

+ 



+- 

I 

+ - 

I 

+- 



EFD 

OICC 



- + 
I 

- + 
I 

- + 



J AO ICC J 



+ 

1 

+ + 

| ROICC | 

+ + 



Figure 2.1 NAVFAC Contract Organization. 



1 . Eng ineerin g Field Divisi ons 

The EFDs are organizationally patterned after 
Headquarters, NAVFAC. A major department of the EFD is the 
Acquisition Department. Four divisions under the supervision 
of the Acquisition Department Director concern themselves 
with the acguisiticr process: 1) Acquisition Project 
Management Division; 2) Contract Division; 3) Design 
Division; and the 4) Construction Division. 

a. Acquisition Division 

The Acquisition Project Management Division 
performs many general acquisition management functions. Its 
major mission is to monitor and coordinate the execution of 
construction contracts. In this role, the EFD serves activ- 
ities which are located in a NAVFAC designated geographical 
area. responsibility. To meet this program management func- 
tion, the EFD develops listings of prospective A-S 
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contractors, makes selections or contractors for specific 
design contracts and negotiates contract fees. Once 
contracts are awarded, the staff coordinates and reviews 
contract design and construction matters. Any proposed 
changes in the scope of contracts are reviewed by this 
office. 



b. Contract Division 

The Contract Division is concerned with the 
legal contractual matters and the contract administration 
process. This division provides the field OICC and EOICC 
with interpretations of contracts, policy guidance and 
recommendations on claims. Basically, the Contract Division 
acts as a consultant to field contracting offices on more 
difficult contractual matters. 

c. Design Division 

The Design Division is a "government-cwned 
Architect and Engineering organization 1 ’ so to speak. It 
performs the same design functions that most commercial A-E 
firms prcvide. Approximately 25% of the Design Division's 
effort is strict engineering design with the remaining 75% 
directed toward engineering contracts management and 

consulting. The Design Division reviews A-E contracted 
designs to ensure maximum utilization of design criteria for 
economical design cost and quality construction. For field 
activities they review all field designs and provide 
technical consultation on design matters. 

d. Construction Contract Management and 

Administration Division 

The Construction Contract Management and 

Administration Division manages construction executicr to 
achieve timely, quality construction. This division receives 
support from the three other divisions mentioned above. 
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2 . 



Na val Shore Activities 

Each Naval Shore Activity Commanding Officer has cn 
his staff a Civil Engineer Corps officer who is responsible 
for the facility management of the station. This officer 
will he either the Public Works Officer (PWO) or a Staff 
Civil Engineer (SCE) who in turn will interface with the 
station PWO. This officer and possibly his staff will 
ensure the NAVFAC mission is carried out as described above. 
The EFD, OICC, and ROICC support the PWO/SCE. The PW O/SC 2 
navigates projects through these offices requesting the 
services required tc properly manage the maintenance, 
repair, alteration and construction of local Naval Shore 
assets. 

3 • Of ficer In Charge of Constructi on 

The OICC receives designs and contract specifica- 
tions from the EFDs and the PWO to be awarded as construc- 
tion contracts. The OICC maintains lists of prospective 
contractors as well as issues Request for Proposals and 
Invitations for Bids. Contractors are screened by the OICC 
staff to determine if they qualify to bid on Navy construc- 
tion contracts. This OICC office awards the construction 
contracts, issues change orders to existing contracts and 
approves performance payments. The official contract files 
are maintained by the OICC. 

4 . Residen t O fficer In Ch arge of Construct ion 

The ROICC administers the construction contracts 
awarded by the OICC often physically located at the EFD. The 
ROICC is also functionally responsible to the local Naval 
Shore activity to ensure the contractor provides the best 
guality construction permitted under the contract. The ROICC 
works directly with the contractor in the daily execution of 
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the contracts. This interface includes inspections of wo 
review cf material sutmittals; approval of payment regues 
schedules, estimates, shop drawings, etc; and the review 
surveillance of the contractor's Quality Control system. 

These four organizations, from EFDs down to 
ROICC, constitute the contracting family of NAVFAC. 
focus in this thesis is on those elements of the ROICC 
Naval Shcre Activities which are concerned with contrac 
A-E design efforts. These are the organizations who wo 
benefit the most from the micro-computer based managem 
system proposed herein. 
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III. BACKGROUND 



A. NAVAL FACILITIES SYSTEM 
1 * S ystem O verv iew 

NAVFAC has a single Automated Data Processing System 
called the Naval Facilities System (NFS) . The automated data 
processing plan for the command is published annually in the 
NAVFAC F-424 , the Naval Facilities System Plan [Ref. 1], 
This plan provides the short and long range ADP corporate 
planning for NAVFAC. The intent of the plan is to optimize 
the information technology currently available and integrate 
existing management systems to permit the managers of 
programs to more effectively meet their missions. The plan 
is coordinated with and developed in conjunction with the 
Command Management Plan, the NAVFAC command budget and the 
Navy ADP budget. 

The NFS is an accumulation of 15 interfacing 
Automated Information Systems (AISs) . These systems are 
utilized in determining the requirements, making the acqui- 
sitions ana monitoring the utilization of real property, 
utilities, and all forms of civil engineering support. 
Figure 3.1 shows the relationship between the Requirements, 
Acquisition, and Utilization of Real Property, Utilities, 
and Civil Engineering Support. Naval Force Planning deter- 
mines base loading, some required human resources ana the 
mobilization plans. The mobilization plans generate a 
requirement for Civil Engineer Support which further places 
a need for human resources which in turn further increases 
base loading. The requirements for real property and 
utilities are determined once these needs are identified. 
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Figure 3.1 Navy Facilities System 










Acquisition of real property, utility systems and equipment 
are budgeted for and then carried out. The combined utiliza- 
tion of the real property, utilities and equipment produce 
the desired capability espoused by the Naval Force Planning. 
Four AISs are of importance to this thesis. These AISs are 
Management Information Systems (MIS) for use by NAVFAC 
Headquarters, the Engineering Field Divisions (EFD) , the 
Construction Battalion Centers (CBC) , and the Public Works 
Centers (PWC) . The other 11 AISs are functional as 
Navy-wide applications in environmental protection; in shore 
facilities planning and real estate; in military construc- 
tion programming; in support of the Naval Construction 
Force; in construction, automotive, and special equipment; 
in base engineering Support, energy conservation, engi- 
neering research, family housing, base operating support; 
and in occupational safety and health/deficiency abatement. 



Data Base Management Sys tem 



The accumulation and management of the data required 
to support the 15 AISs presents a management challenge. 
Since the mid-70’s the thrust in supporting these AISs has 
been to adapt a generalized Data Base Management System 
(DBMS) approach. Conversion to a DBMS from a conventional 
file oriented systems is a time consuming process. This 
approach continues today to replace the existing file 
oriented system of the NFS where a particular application 
has to have it’s own data file. A database management system 
is a software tool that is designed to manage and maintain 
an organization’s database resource. The DBMS itself is not 
tied to any particular set of files. [Eef. 4; p.333] 



a. Benefits of the DBMS 



The conversion to a DBMS has many long term 
benefits. Data captured in the database becomes application 
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independent. The data structure of the data in the database 
remains the same no matter what the application, causing 
some standardization of application development since all 
applications must access the same structured data. However, 
this does not limit the applications since applications can 
build different views of the data simply by accessing and 
merging the data to suit the application needs. For example, 
one program could be written to track contracts in separate 
geographic areas. The program could produce reports based 
on just one region or it could combine or extract data from 
the database to produce a NAVFAC-vide report. 

Existing software is able to provide logical as 
well as physical data independence, enhancing the data 
storage economies. Eedundant data need not be stored for 
several applications. The evolution of the database can 
proceed without the spiralling cost of maintenance for 
application programs. There no longer needs to be updates to 
application programs due to data changes. With DBMS comes 
utility programs to assist the Data Base Administrators 
(DBA) to act as controllers and custodians of the data to 
ensure integrity of the data and enforce the proper struc- 
ture. (The centralized database system currently in use 
will be discussed later in this chapter.) Along with integ- 
rity comes the requirement to protect the data through 
proper security measures. The data for the most part is 
unclassified administrative data for military purposes, yet 
it is in a sense administratively confidential and must 
therefore be protected. Access to the database must be 
limited to those who have a need to know. The DBMS utilities 
will accommodate this requirement also. Since the DBMS is 
generalized, data migration across devices can be facili- 
tated much easier as the proliferation of hardware 
increases. In governmental systems this is important consid- 
ering the limitation of the ADP procurement policies. 
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Managers of systems can not always predict the brand of 
hardware a particular procurement action will produce. 
Another consideration is that of an evolving functional 
distribution system. As the system grows horizontally or 
vertically, the new nodes that are placed on the system may 
or may not be compatible with existing system hardware. 
Existing equipment must be either directly compatible or 
must be able to interface through various protocols. 

A current goal of the NFS is the development of 
a complete data dictionary to cover all the AIS. This is 
imperative for the proper control of the data validity. The 
data dictionary standardizes the data formats and the actual 
meaning cf the data elements for all command systems. This 
is not new to the AIS but simply a feature to have a fully 
functioning DBMS. The DBMS also permits various levels of 
access to the database. The DBA is be able to define the 
structure of the database through the use of the data defi- 
nition language (DDL). The DDL includes terms for defining 
records, fields, keys, and relationships. It also provides 
facilities for expressing a variety of user views and allows 
the imposition of user constraints such as editing capa- 
bility, interrecord and intrarecord browsing. Access to the 
database by application programmers is through the use of 
the database command language. Applications can be written 
for novice users of the system at EFDs and field activities 
such that the details of accessing the database are 
completely transparent. For more sophisticated users who 
wish to access the database directly, a query language is 
available. This permits queries to be made of the database 
to obtain quick answers to unanticipated or one-time 
guer ies. 
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t. Advantages of a DBMS 

A generalized DBMS has many advantages over a 
conventional file oriented structure. The DBMS allows more 
information to be pulled from the same data. Consider a 
distributed system where field RGICC offices would be able 
to access a large database. Several applications could be 
made from the same source data. For example, contract admin- 
istration on a series of contracts could be used to track 
the current workload at the ROICC level. The same data at 
the EFD level could he used to review the distribution of 
design efforts over the EFD 1 s geographical area of responsi- 
bility. At the NAVFAC level the same data could be used by a 
program manager in tie development of budget estimations for 
the upcoming budget process. The partitioning of data in a 
conventional file system makes the process of gathering data 
for these different applications difficult. In the conven- 
tional system, to avoid this difficulty it becomes necessary 
to maintain a file for each application creating vast 
amounts of data redundancy. Thus the DBMS saves memory 
space, speeds processing and data entry, as well as enhances 
the data integrity. 

c. Disadvantages of a DBMS 

With any improved system there also exist seme 
disadvantages and turning to a generalized DBMS from a 
conventional file oriented system is no exception. DBMSs are 
expensive to procure and implement requiring longer term 
benefits to justify the initial cost. A generalized DBMS can 
require a new series of processors. This is important if 
the corporate processing involves more than just database 
processing. A dedicated processor is often the best invest- 
ment since it will permit parallel processing of database 
accesses and applications. Highly trained personnel are 
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required to maintain the DBMS environment and administration 
and control of the DBMS is more complex than the file 
oriented systems. Administrative and operating cost can be 



expected to increase, 
comparing them to tie 
benefits of the DBMS 
system can easily 
disadvantages. 



Considering the disadvantages and 
overall advantages, the long term 
over the conventional file oriented 
justify any of the mentioned 



3 • D is tribut ing The S yste m 



Another NFS initiative which reflects the changing 
philosophy of NAVFAC is that of expanding the number of 
users of the NFS. This expansion is being accomplished 
through decentralization and distribution of the NFS. 
Froject smart (source management of resources and time) is 
being implemented for use at the EFD/OICC level. The project 
consists of installing minicomputers at the EFDs and CICCs 
to permit the implementation of local management tools and 
the standardization of existing office automation systems. 
The objectives of project smart are: 

a) provide additional processing capability for the 

EFD/OICC; 

b) achieve system revision and integration through 

evolution net revolution; 

c) provide a user friendly interface to permit query 

language access to the generalized DBMS; 

d) develop local application's from the initial instal- 

lation. 

Project smart is scheduled to be fully implemented in all 
EFDs and NAVFAC HQ by the end of FY87. [Ref. 1: p.5-10] 

Another form of distributing the NFS has teen the 
decision to provide "teleprocessing" to the EFDs. Hardware 
has been connected from the Facilities System Office (FACSO) 
in Port Hueneme, Ca. to the EFDs and to NAVFAC HQ through 
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the use cf telecommunication lines. The hardware includes 
terminals for input/output operations, and hardcopy 
printers. The remote sites can input data directly tc the 
nain computer at FACSC as well as receive management reports 
at local printers. This type of distributed processing has 
proven tc be more effective and efficient than the totally 
centralized approach used previously. [Ref. 1: p.5-1]. The 
benefits include reduced input time, a more accurate data 
discipline, and improved delivery time for outputs. 
Reporting requirements have also declined due to the ability 
of the user to make cr-line queries of the database. 

4 . Automa ted Infor matio n S ystems 

Of the 15 AISs, only the EFD/MIS will be focused 
upon in the remainder of the thesis. The EFD/MIS serves the 
management requirements of the EFDs, large OICCs and NAVFAC 
HQ. This distributed data processing (DD?) configuration is 
shown in figure 3.2 below. The major data systems cf the 



MIS are: 

(1) The 



Data Base which supports the 



"AMALGAKAN" 
following: 

(a) Integrated Disbursing and Accounting (IDA) 

(b) Integrated Program Management System (IPMS) 

(c) Construction Management System (CMS) 

(2) Design Management Information System (DMIS) 

(3) Graphics Design System (GDS) 

(4) Contractor Information System (CIS) 

The EFD/MIS has over 200 computer programs and produces 
approximately 200 standard titled reports. [Ref. 5: p.i] 

The data systems which are of primary interest to the EOICC 
are the CMS, DMIS and the CIS. 
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Figure 3.2 EFD/MIS DDP Configuration 





a. Construction Management System (CMS) 

The objective of the CMS is to provide the 
NAVFAC level program managers with the information reguired 
to monitor and control the design and construction phases of 
shore facilities projects. The reports produced provide 
Project Status (used by EFD/OICC and HQ), Execution Status 
(used by EFD and HQ), Work In Place (used by EOICC, 
EFD/OICC, and HQ) and various other management reports. 
[Ref. 5: p-31] 

h. Design Management Information System (DMIS) 

The DMIS is utilized by HQ and EFD/OICC design 
managers to manage the engineering and design phases of the 
NAVFAC mission. Three functional areas are directly 
supported: design scheduling, criteria scheduling, and engi- 
neering and design maragement. 

( 1 ) Design Sche dul in g. 

Design scheduling involves design job 
status, design scheduling, personnel resource allocation 
(in-house vs. contract), job cost control, and design 
performance appraisal. 

(2 ) C riteria Schedulin g . 

This application involves the design 
schedule, milestones, and funding information used in sched- 
uling and coordinating the preparation of design criteria. 
The system is used to plan goals that will be established in 
the Command Management Plan (NAVFAC P-441), and to document 
the progress of the design goals which have already been 
established . 

(3 ) En gine ering and Design Managem e nt . 

Used by EFD/CICC and HQ program managers, 
this application combines data from several data files and 
aggregates it to a high level to monitor the progress of 
projects at the EFD/CICC and HQ levels. 



29 



c. Contractor Information System (CIS) 

The CIS is designed: 1) to standardize proce- 

dures for maintaining contractor information for the A-2 
slates and mailing lists; 2) maintaining history of the 
contractors efforts for the U.S. Navy; and 3) providing 
contractor data to the CMS and IDA systems [Eef. 6: p.1]. 

The CIS is utilized ty all levels of NAVFAC management for 
all varieties of contractor information. The information for 
the CIS is drawn from contractor submitted questionnaires 
(A-E and Belated Services SF 254) and Bidder’s Mailing List 
Application (SF 129) . Updates are made periodically as more 
information is accumulated on various contractors through 
submittal of follow-cr SF 254s. 

d. NFS Goals for the EFD/MIS 

The NFSP , [Bef. 1: pp.1-12 - 1-21] outlines 

several short and lcng term goals for the EFD/MIS which in 
general lead toward a distributed data processing system 
where the end-user will be able to work directly from the 
generalized database system in a virtual mode. Some specific 
goals are: 

* Implement automated procedures for reporting 

individual procurement actions (DD 350 reports). 

* Develop a word processing/central processing 

interface for the ROICC. 

* Convert AMA1GAMAN/CMS to DBMS with on-line query 

capabilities. 

* Implement Graphics Design System at the EFD and HQ 

levels. 

* Convert the DMIS to D3MS for on-line query 

capabilities. 
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B. F ACUITIES SYSTEES OFFICE 



The Facilities Systems Office (FACSO) is the huh cf the 
NAVFAC data processing system. Located at the Construction 
Eattalicn Center, Port Hueneme, Ca., FACSO is responsible 
for the majority of the development and operation of the 
NFS. FACSO’s distributed network is shown in figure 3.3 
below . 

FACSC has an IBE 370/165-11 computer system with 4 
million characters of main memory, 22 gigabytes of on-line 
storage, 26 tape drives, 2 high-speed non-impact printers, 
and 6 high-speed impact printers. Two coupled Interactive 
Data Ease Processors (IDBPs) with 4 million bytes of memory 
each were installed in 1981/82. The IDBPs handle all data- 
base applications and share most of the peripheral equip- 
ment, thus relieving the 370/165-11 of considerable 
workload. A COMTEN 3690 Front End Processor handles the 
majority of the telecommunications interface. The device is 
programmable and switchable so that a given port can handle 
different types of input terminals and route messages under 
program control. Communication ports are assigned 
dynamically to accommodate the fluctuating load. [Ref. 1: 
p.4-1] 
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Figure 3.3 NFS Distributed Network 



C. LIBITATIONS OF TBE NAVAL FACILITIES SYSTEM 

The paragraphs aiove have briefly explained the NFS and 
in particular the EFD/MIS. The life of the NFS continues to 
be a dynamic one as are all long term data processing 
systems. The system has shown all the signs of growth as 
described by Nolan [ Eef . 7 : pp. 115-126]. The system began 
as a central data processing point where all input was 
either sent via the postal services or transmitted electron- 
ically via message. The data was required to be key punched 
on data cards and submitted in a batch mode with output 
reports sent to the users via the postal service. The time 
lapse from the time the field activities submitted their 
data to FACSO (via the EFD) to the time the output reports 
were received could be as long as five months but was 
normally in the order of at least three months. This manage- 
ment system did not meet the management needs of the field 
activities. Today however, the NFS provides the EFD s and 
NAVFAC HQ tetter management support due to the advances in 
telecommunications and the availability of distributed 
processing at the EFD level. 

A large majority of the data for the EFD/MIS comes from 
the field EOICC offices. These offices accumulate this data 
over a period of a month, in most cases manually, and submit 
it to the EFD where it is validated and transmitted directly 
to FACSC through use of the EFD/MIS DDP system (Figure 
3. 2). The EOICC office will normally receive a management 
report within six weeks. This data is in the most part 
historical and can net be used to effectively manage a day 
to day operation. Therefore the collection and reporting of 
the data is only an overhead expense to the field activity. 

Plans for the future for the NFS call for the field 
activities to have a virtual connection to FACSO just as the 
EFDs enjoy now. This will permit the EOICC to collect data 
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electronically and in turn transmit probably via the EFD 
processors to FACSO. The ROICC will also be able to keep 
on-hand the data for management of daily operations. These 
advances are just beginning to be seen for some 50ICC 
offices. WANG Office Information System (OIS) hardware/ 
software is used to permit collection of required data. The 
data is presently transmitted to the EFD by mailing disks. 
Direct transmission to the EFDs is not possible at the 
present time. A main concern of this thesis is investi- 
gating a method by which the field activities can locally 
utilize the data which is collected for higher level manage- 
ment. Currently, the majority of the data remains to be 
historical in nature. Systems can be developed which will 
incorporate the collected data into the daily management 
functions of the field activity. The remainder of the chap- 
ters will be devoted to the development of such a system for 
the management of the A-E contracting process. 
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IV. J-E CONT RACTING PROCESS 



A. GENERAL 

As mentioned earlier, A-E contracts are used primarily 
to procure the drawings and specifications for contemplated 
construction projects [Ref. 2: p.2.1.1]. These contracts 
are awarded throughout the NAVFAC contracting chain. While 
all the contracts are awarded by following the same required 
contractual procedures [Ref. 2], the actual process will 
differ from command to command due to differing management 
styles of individual managers and the local "traditional 
policies". The process described below is generic in the 
•sense that all the A-E contracts go through the same three 
phases no matter which command is concerned. There are many 
rules and regulations which govern the process but it is net 
the intent of this chapter to fully discuss all the legal 
requirements of contracting but rather to focus primarily on 
the process and the accompanying information flow that the 
manager must be aware of in order to manage the process. 

Within the A-E type of procurement there are several 
different types of contracts. The main difference in the 
various types is the number of "actions" or "products" which 
can be delivered under one contract. Some contracts, 
normally larger in award amount, require the design of one 
construction project. Other contracts are "open-end" in that 
a larger number of designs, normally small in nature, can be 
accomplished under one contracting vehicle. Open-end 
contracts often are not to exceed a predetermined total 
amount. These contracts are negotiated based on hourly fees 
for particular technical skills rather than for a total 
design cost basis. Follow-on work is negotiated based on 
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the hours required tc accomplish a design task which is then 
translated into an award fee. 

The A-E contracting process is broken into three phases, 
the pre-negotiation phase, the negotiation phase and the 
post-award phase. Each transition from one phase tc another 
is marked by a distinct result or action. The pre- 
negotiation phase involves the initial request for a 
contract submitted by a customer. The phase ends when a 
slate of a few contractors is approved by the selection 
official for further consideration. The negotiation phase 
begins with the selection of the best qualified contractor 
from the slate and concludes with the awarding of a negoti- 
ated contract. Post-award is the actual contract execution 
phase. It begins immediately upon the signing of a contract 
and finishes when all contracted work has been accepted by 
the government and final payment to the contractor has been 
made. 

There are several parties involved in the contracting 
process. These include the contracting officer (OICC, 
ROICC, AEOICC) , the customer (organization whom the design 
is to benefit), the contract administration staff, govern- 
ment engineers (review the contractor's work and accept it 
as being correct), and lastly the contracted A-E firm. The 
parties are involved to differing levels throughout the 
contracting process as will be seen in the following 
paragraphs. 

B. P BE- NEGOTIATION PHASE (I) 

The steps in the Pre-Negotiation Phase (I) are carried 
out primarily by the contract administration staff. Other 
key participants in this phase are various board members as 
well as the customer. The customer may be someone in the 
immediate contracting organization itself or maybe an 



36 



organization which is supported by the contracting office. 

Figure 4.1 is a flowchart depicting the steps listed below. 

1.1 Request for contract - The contracting officer receives 
a reguest for an A-E contract. A determination has 
already been made that the design cannot be handled by 
the in-house engineering staff. 

1.2 Contract Specialist (CS) assigned - The contracting 
officer assigns a CS to handle the contract request. 
This CS may administer the contract from the beginning 
of the contract to the end or the CS may simply handle 
the contract until the award is made, depending cn the 
local policy. 

1.3 Development of Statement of Work (SOW) - The requesting 
customer or the in-house engineering staff will develop 
the SOW for the contract. The CS reviews the SOW for 
completeness and correctness. The developer of the SOW 
draws up the weighted criteria by which the best 
qualified contractor can be selected. 

1.4 Detailed Government Estimate (GE) - In most cases the 
writer of the SOW also draws up the GE. 

1.5 Reguired Clearances and Approvals - Depending on the 
type of funds used for the design and the type of 
design, certain clearances and/or approvals may be 
necessary from higher command levels before further 
action can be taken in the contract process. 

1.6 Small Business Set Aside Recommendation - A 
determination must be made as to whether the contract 
will be open to large business or remain as a small 
business set aside. 

1.7 Commerce Business Daily Synopsis (CBD) - The CS will 
prepare the synopsis for the CBD and ensure that it is 
mailed. The CBD announcement is a notice of intent to 
contract. 
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Figure 4.1 Pre-Negotiation Phase Flowchart. 
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1.8 Logging of SF 254s and 255s - Contractors responding to 
the contracting announcement in the CBD are required to 
submit their firm's qualification on the SF 254 (general 
contractor information) and the SF 255 (contractor 
information directed toward a particular announced 
contract action) . 

1.9 Board Appointment Letters - The A-E contracting process 

requires’ three contract boards: pre-selection board, 

selection board, and the negotiation and award beard. 
Appointment letters assigning the members of the board 
must be sent out. 

1.10 Pre-selection - The pre-selection process is carried 
out by the pre-selection board. All contractors submit- 
ting a SF 255 for the contract are considered. The SF 
255s are reviewed by the board members and the field of 
qualified contractors is narrowed to a manageable 
number. The board members are guided in their selection 
of the qualified contractors by the selection criteria 
developed by the customer or engineering staff. The 
slate of qualified contractors is approved by the 
approving authority (based on the amount of the 
contract) . The approval of the pre-selection board 
report by the proper authority is the concluding action 
of the pre-negotiation phase. 

C. NEGOTIATION PHASE (II) 

The Negotiation Phase carries the process through the 
actual award of the contract. The customer plays a minimal 
role in this phase with the key players being the pre- 
selected contractors, the selection and contract award 
board, the selected contractor and the CS. Figure 4.2 
depicts the negotiation steps listed below. 
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Figure 4.2 Hegotiation Phase Flowchart. 
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11. 1 Interview Letters - Those contractors approved on the 
Pre-Selection Board report are sent letters to inform 
them of their pre-selection and to establish a time and 
place for an in-depth interview before the Selection 
Board. 

11. 2 Interview of the A-E firms - Individual interviews are 
conducted for each A-E contractor. The Board members 
evaluate the contractors against the criteria published 
in the CBD announcement. 

11. 3 Selection of a contractor - Based on the interviews, 
the Selection board members select a contractor who best 
satisfies the selection criteria. A Board report is 
prepared and signed by all members of the Board. The 
proper approving authority (depending on the amoant of 
the contract) will either approve or disapprove the 
selection of the Board. 

11. 4 Request for Fee Proposal - A request for a fee proposal 
is sent to the selected contractor. Depending on the 
size of the contract, various documents may also be 
required of the contractor. 

11. 5 Receipt of the Fee Proposal - The fee proposal when 
received is forward to a lead engineer for review. The 
engineer may or may not be the customer. In a 
multi-disciplined contract, the proposal may be sent to 
several engineers. The engineers may be on the Selection 
and Award Board as well. Here again, depending on the 
size of the contract, various clearances may be 
required. 

11. 6 Pre-negotiation - The lead engineers in conjunction 
with the CS will perform the pre-negotiations with the 
contractor. This can result in revisions of both the 
government estimate and the contractor estimate as well 
as clarifications of the SOW. All actions which take 
place are recorded by the CS. 
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II. 7 Negotiation Board meeting - Once negotiations with the 
contractor are settled, the Negotiation Board is called 
to meet in order to review the negotiation proceedings. 
If the proceedings are agreeable to all the board 
members, the board report is prepared and signed by all 
the members and is then forwarded to the proper approval 
authority for approval. 

11. 8 Negotiation Beard Heport Approval - The approving 
authority reviews the Negotiation Board report and 
approves or disapproves. 

11. 9 Contract Award - Once the approving authority approves 
the Negotiation Ecard report the contract can be signed 
by the proper authority. The signed contract is then 
sent to the contractor for signature. 

D. PCST-AWARD PHASE (III) 

The Post-Award Phase carries the contract process 
through management and administration to the final payment 
and closing of the contract. The normal players in this 
phase are the contractor, the lead engineer who will review 
the contractor’s drawings,* and the CS who must process the 
payments for the contract. The contracting officer may get 
involved if problems arise in the contract. Figure 4.3 
illustrates the steps of this third phase. The contract 
modification steps are not shown here since the same steps 
are followed as in the negotiation phase. 

111. 1 Notification letters - letters are sent to all the 
non-selected contractors. These letters inform the 
contractors of the contract award. 

111. 2 Individual Procurement Action (DD Form 350) - Contract 
actions exceeding $10,000 reguire the filing of a DD 
Form 350. This form is normally submitted to the EFD. 
The form contains information pertaining to the awarded 
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Figure 4.3 Post-Award Phase Flowchart. 
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contract and the procedures utilized in awarding the 
con tract. 

111. 3 Other Reports - Depending on the size of the contract, 
it may be necessary to notify NAV FAC of the award and 
also submit an award announcement to the CED. 

111. 4 Distribution of Contract - Once all the signatures are 
obtained, the contract can be reproduced. The contractor 
will be sent several copies as will the EFD 'and the 
customer. 

111. 5 Contractor Meetings - Prior to the actual beginning of 
the design effort, it may be necessary to meet with the 
contractor to discuss administrative matters or design 
specifics. Similar meetings may occur throughout the 
life of the contract. 

111. 6 Design Reviews - Design reviews are for the purpose of 
reviewing the contractors work to ensure the government 
is obtaining the design as reguested. It also is a key 
feedback mechanism to ensure customer satisfaction. 
Design reviews occur normally when the designs are at 
the 30%, 60%, 90% and final or 100% complete points. If 
the design is time critical, the 60% review will 
normally be waived. The lead engineer will coordinate 
the reviews with the customers. The customers are often 
non-technical and the lead engineer serves as the 
"interpreter”. The lead engineer communicates to the CS 
whether or not the submittals meet the specifications of 
the contract. The relationship between the CS and the 
lead engineer is of upmost importance in the post-award 
phase. 

111. 7 Contract Modifications - Contract modification 
procedures are very similar to the procedures in the 
pre-award phase. The procedures are as follows: 

1} Request for contract modification - This would 
normally be in the form of a request for 
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additional work or for a time extension for 
existing work. The customer will generate the 
request for additional work and the contractor 
would request the time extension. 

2) Changes Board appointment letters - Letters are 

sent to Change Order Board members notifying them 
of the time, place and circumstances of the 
change. 

3} SOW revision - The SOW is amended to reflect the 
change. 

4) Preparation of the GE - The GE is developed by the 

lead engineer. 

5) Request for Fee Proposal - The revised SOW is 

forwarded to the contractor with a request for 
the firm tc provide a fee proposal. 

6) Receipt of Fee Proposal - The contractor’s Fee 

Proposal is received by the CS and forwarded to 
the lead engineer for review and validation. 

7) Pre-Negotiation contact with the contractor - The 

contractor is contacted by the lead engineer and 
the CS to discuss differences in the contractor’s 
estimate and the GE. If required, any 

clarifications are made and a preliminary 
agreement is established. The GE or the 

contractor’s estimate may be adjusted as 
appropriate. 

3) Preparation of the proposal analysis for the 

negotiation board - The CS will prepare an 
analysis for review by the change order 

negotiation board. The analysis will cover all 
the preliminary discussion between the contractor 
and the CS/lead engineer team. 

9) Change order negotiation board meeting - The board 
meets to discuss the CS’s prepared analysis and 
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to determine if the contractor’s proposal is fair 
and reasonable. 

10) Board report preparation - The CS prepares a 
board report for all the board members to sign. 

11) Approval cf board report - The signed board 
report is submitted to the approving authority 
for approval. 

12) Signing of the Change Order - The approving 
authority signs the Change Order for the 
government. 

13) Contractor sent Change Order - The signed Change 
Order is sent to the contractor. 

111. 8 Progress Payments - Periodically the contractor will 
submit a request for a progress payment to the CS. The 
CS will obtain an endorsement from the lead engineer on 
the request. Based upon the lead engineer's endorsement 
and upon the CS's own knowledge of the progress cf the 
contractor, the CS will forward the request for payment 
to the proper government disbursing office. 

111. 9 Disputes, errors and omissions, design deficiencies, 
A-E liability - The Contracting Officer, CS, lead 
engineer, and the contractor will be involved in the 
resolution of these matters. These matters are normally 
resolved at this low level but may progress through a 
complex process leading ultimately to court action if 
necessary. 

111. 10 Final Payment - When all design work has been 
completed and accepted by the government, the contractor 
will submit his request for the final contract payment. 
This payment is processed in a similar manner as 
progress payments except that the contractor is paid the 
full remaining balance of the contract fee with no 
contingency withheld. 
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III. 11 Contractor Release - The contractor is released from 
the provisions of the contract once all work has been 
completed and final payment has been made. 

III. 12 A-E Performance Report (DD 14 13) - The A-E 

performance report is a summary of the contractor's 
performance during the life of a particular contract. 
The CS will reguire the lead engineer to fill out the DD 
1413. This report wilj. remain in the contractors file 
for future reference on other contract considerations. 
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V. RETIREMENTS DETERMINATION 



A. 1SHY AN AUTOMATED SYSTEM? 



The NAVFAC history on Automated Data Processing as 
mentioned earlier goes back to the 1950’s. ADP has progres- 
sively proven to be a more advantageous tool to use in the 
area of facilities management. The Naval Facilities System 
has been built around the concepts of ADP and the emerging 
technologies of the computer revolution. One goal of the NFS 
is to extend the management resources available to the field 
activities. This process of distributing the ADP capabili- 
ties is evolutionary in nature with the EFDs becoming 
increasingly more ADP oriented. The next phase of the evolu- 
tion is to reach the commands and field activities supported 
by the EFD . Several of the EFDs have begun to provide the 
field activities with computer hardware and software which 
will enable them to develop applications on the local level 
as well as communicate directly with the EFDs. Most of the 
communications planned will require use of commercial tele- 
communication lines for distributed processing. Unlike field 
activities in the continental United States, overseas activ- 
ities have problems with this form of communication. The 
costs and reliability factors as well as protocol complica- 
tions make transoceanic telecommunication of data imprac- 
tical at this time. These activities must depend therefore 
on local independent computer systems. 

Automation is not appropriate for every situation. For 
some processes, total automation can be achieved and will 
result ir many benefits, while other processes do not lend 
themselves to automation and should remain manual. The A-E 
contracting process falls in the middle of the spectrum. 
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There are several benefits the ROICC can gain by automating 
portions of the process. Consider the following: 

Time Savings - The A-E management procedures require a 
sizeable amount of correspondence, reports and stan- 
dard memorandums. In an automated system form, 
letters, reports and memorandums are required to 
only be written one time. Form correspondence such 
as this only requires that unique information be 
inputted. This input can be made either from a data- 
base or in response to on-line queries. In advanced 
electronic office environments, much of the in-house 
correspondence can be sent via electronic mail 
producing time savings for both staff and managerial 
personnel. In considering the time required to 
locate information in a file, a computer based 
system utilizing a database management system can 
provide the information by simply responding to a 
query. The computer will locate the information as 
opposed to an individual having to manually look 
through a physical file. 

Accuracy - There is a potential for greater accuracy. 
Once the data is entered into the system in the 
proper format, it is not necessary to reenter it. 
This reduces the number of times the data needs to 
be physically handled. Selective user interfaces 
and error reducing screen formats can aid greatly in 
reducing the number of data entry errors. 

Data Collection - Methods for collecting the data can be 
much faster than manual systems. User interfaces can 
be designed to prompt the user for the data. 
Properly designed prompts and input screens remove, 
in a number cf cases, any questions staff personnel 
have regarding the proper data. 
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Data Storage - Manual systems reguire the collection of 
a high volume of redundant data. Computer based data 
storage can utilize database management systems 
which will greatly reduce the need for redundant 
data. As mentioned earlier, data in one database can 
be utilized to satisfy more than one requirement. 
This also reduces the size of the data storage. As 
an example, in the contract process, the name of a 
contractor normally appears on most of the contract 
documentation. With a database management system, 
the storage of this information would cnly be 
required once. Follow-on reports or correspondence 
could be provided the contractor’s name from the 
database . 

Personnel Turnover - In many cases an automated system 
can ease the problems associated with the turnover 
of personnel. The automated system if properly 
designed can guide new personnel in the work 
process. With built-in help facilities, the computer 
can be referenced when questions arise. Also for 
data entry, set formats provide the new personnel 
with a template for input process, removing seme of 
the ambiguity of a new system. 

Costs - Most improvements to a process result in cost 
savings. Computer based systems are no exception if 
they are properly designed to fit both the organiza- 
tional needs and the process. Cost savings are seen 
in personnel, supplies (less paper in some systems), 
and time savings from data entry, storage, and 
retrieval. 
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B. THE COHPOTEF.-BASEE ENVIRONMENT 



For the proposed automated A-S contract management 
process to be effective, it should provide the benefits 
described above. Aron [Ref. 8: pp. 213-236] describes three 
levels cf information system design for organizational 
information systems. The levels are: 

1) simple data processing system 

2) integrated file-oriented data processing system 

3) management information system 

A fourth level would be information resources management 
systems (IRMS) , a concept on the current edge of information 
systems technology. Each of the higher level systems 
include the elements of the lower level systems since the 
development of the systems from the first to the fourth has 
occurred in an evolutionary process. Let's consider each 
level individually in relationship to the A-E contract 
management process. 

1 . Sim ple Data Processing System 

The simple data processing system consists of a 
number of independent transaction-oriented tasks which 
summarize inputs to produce reports. The ROICC may want to 
know at the conclusion of the fiscal year how many contracts 
were awarded for A-E services. A simple data processing 
system approach to this request is shown in Figure 5.1. 
During the year, as each contract is awarded, an input could 
be made into a computer which would give the data for the 
contract such as the contract number, title, A-E firm and 
the fee. A program could be written to take this input and 
produce a report at the end of the year which would summa- 
rize the number of contracts and the total dollar amount of 
fees awarded. This same approach could be made for a number 
of desired reports. The disadvantage of this type of system 
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Figure 5.1 Simple Data Processing. 

is that the reports are historical in nature and tend to 
provide only record type information. Simple data processing 
systems which produce historical data, do not lend them- 
selves to the day to day dynamic management requirements of 
the RCICC. 

2 . I ntegr a t ed Fil e-Orie nted Data Proce ssing System 

Most shortcomings of the data processing system are 
overcome by the development of the integrated file-oriented 
data processing system. The integrated file-oriented data 
processing system structures data such that facts can be 
extracted according to many different criteria. A contractor 
information system maintained by the ROICC can contain data 
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on contractors who either do business with the Government or 
who desire to be considered for upcoming contracts. The data 
is stored in a series of files made up from information the 
contractor has submitted via the SF 254 and possibly the SF 
255. These forms provide demographic information on the 
contractor as well as the composition of the firm by disci- 
pline and a short concise history of the firm's past 
contract experience. The ROICC utilizing an integrated file- 
oriented data processing system can determine for example 
which contractors on record have the proper mix of engi- 
neering disciplines to perform a certain contract. This 
would be accomplished as shown in Figure 5.2. The data from 
the SFs would be inputted to database files as the forms are 
received by the ROICC. A series of program would be used by 
a supervisory program to select and extract the needed 
information from the proper data files in the database. The 
output would be formatted by one of the programs in the 
series and produced either as a newly created file or as a 
hardcopy report or as both. 

3. Man agement I nf or mati on S yste m 

The MIS adds another block to the information system 
structure. The MIS adds the foreknowledge of what decisions 
must be made by the ROICC in managing the contracting 
process. The MIS is an integrated system for providing 
information to support planning, control, and the operation 
of the RCICC shop. Figure 5.3 shows the basics of a typical 
MIS. The MIS combines the data bases of the integrated 
file-oriented system with a database of inference models and 
models for evaluation criteria. Application programs kept on 
file are utilized to draw data from the three databases to 
assist the ROICC in making decisions. The ROICC using a MIS 
could be guided to the proper reports required by a certain 
contract type or size. The MIS would evaluate the contract 
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Figure 5.2 Integrated File-Oriented Processing. 

based on the size of the contract fee to determine which 
approvals would be reguired. The MIS would make tnis 
requirement known and then would proceed to collect the 
information from the main database to create the report and 
produce it either for viewing on a CRT or in hardcopy. 

4. In form ation Re sou r ce M anagem ent System 

The Information Resource Management System (IRMS) is 
the current technology in information systems. The system is 
the convergence of several information technologies, data 
processing, communications and the automated office. In the 
future, IRMS will permit the ROICC to teleconference with 
the EFD and possibly permit the Award Board to interview the 
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contractor via teleconferencing. Host transactions in the 
contracting process would be accomplished without paper. All 
draft SOWs , drawings and payment requests would be trans- 
mitted electronically. The futuristic IRMS would extend the 
MIS capabilities so that Decision Support Systems would be 
available to the ROICC from EFD resources. 

C. ROICC A-E COHTBACTIHG MIS 

The IRMS is technologically in the future for the ROICC 
and for NAVFAC as a whole. The data processing system and 
the integrated file oriented processing systems seem only to 
automate a currently manual system rather than provide an 
improved management tool. The complete contract management 



55 



function of the ROICC which includes A-E and construction 
contracting management would be well supported by a MIS. The 
A-E contract management process would be only part of that 
system. 

The system to support the EOICC MIS should enable the 
EOICC to do basic word processing, database management, and 
run applications to interface the database and the applica- 
tion programs. The size of the system would depend primarily 
on the size of the contract management task. The applica- 
tions could consist cf different modules: 1) to handle 
report and letter generation; 2) to track the individual 
contract phases; 3) to track the contract workload; and 4) 
to run rule based modules to assist the EOICC in deciding 
where and when to apply various regulations. With the addi- 
tion of communication technologies, the system could be 
connected to the engineering department so that requirements 
such as SOWs and government estimates could be transmitted 
electronically. Further communication capabilities would 
enable the EOICC to send reports and copies of contracts to 
the EFD electronically. 

D. PROPOSED A-E CONTRACTING SYSTEM 

The following three chapters present a proposed auto- 
mated A-E Contract Management System beginning with the 
pre-negotiation phase and concluding with the post-award 
phase. The proposed system is based on the idea of using a 
micro-computer and running commercially available software 
to develop application modules. The concepts used to 
develop the framework of the system are those discussed 
above. The approach taken in the proposal is not the only 
one that will produce a useable automated A-E MIS. It will 
provide the field with a useful management tool at a minimal 
cost through available current technology. As will be 
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discussed later, tie hardware and software utilized to 
implement the proposed system can be used by the field 

activity in other ways. As an example of how such a system 

could be developed and might function, one major module of 

the proposed system, the Contractor Information System 

(CIS) , has teen developed and is presented in Appendix A. 
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VI. ADTOHATICH OF THE PR EGOTI ATION PH ASE 

The Pre-Negotiation Phase will be the initiation phase 
of the majority of the automation of the entire management 
information process. Some functions for this phase will also 
be carried into the second and third phases. Each step will 
be investigated for possible automated procedures in the 
areas of applications, report generation and database appli- 
cations. As will be seen, many of the automation procedures 
will require the interface of these three areas for effec- 
tive building of management tools and improvements for the 
office staff. 

A. BEQUEST FOB CONTBACT (I. 1) 

The contracting officer after receiving the request for 
contract can initiate two automated management tools, the 
phase I/II tracking database and the contract file. The 
tracking database tracks the administrative contracting 
steps of phase I and II and is driven by an application 
module which guides the user through the proper control 
measures. The database would contain a listing of all the 
contracting steps with an estimated completion time calcu- 
lated automatically by the driver application. The base of 
the completion times would be provided by the contracting 
officer. This aspect of the tracking system would permit the 
contracting officer to vary the times based on the condi- 
tions at hand (i.e. year-end obligations, predetermined 
performance criteria, etc.). As the steps are completed, the 
appropriate dates car be entered into the database by an 
automated timestamp. 
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Another feature cf the tracking system is the tickler 
function. This function permits the user to enter the 
current date and be given a listing of all actions which are 
due to be completed cn that day and present a listing of the 
delinquent actions and signify if there is a comment in the 
file explaining the variance. Since delays can be expected, 
provisions exist for the user to adjust the schedule. A log 
in the database will be maintained to record adjustments for 
historical purposes. 

The second management tool is the contract file which is 
simply an electronic file of contract documents and check- 
lists. The contract file is not a static depository of 
electronically produced documents, but along with specific 
application programs will become the most extensively used 
management tool for the CS and contracting officer. The 
checklists in the file will aid the CS in the contracting 
process. Many documents will be placed in this file by 
various application programs. The file will be updated on 
many occasions automatically by the application programs. 
Access to the file is limited by procedures described below. 

E. CCNTEACT SPECIALIST ASSIGNED (1.2) 

The contracting officer will maintain a database of the 
CSs in the organization and the contracts they are assigned. 
He will update the database as a new assignment is made as 
well as update the contract file to indicate the CS 
assigned. This update to the contract file is part of the 
security measures of the system. Only certain personnel 
determined by the contracting officer can access the 
contract file for a particular contract. Each CS and staff 
person is assigned a personal password. To gain entry to 
specific files the person desiring entry must first get 
through a password checking module. Limitations in file 
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entry can be no access, read only access or full access 
which allows both read and write access. The access tc the 
file can be changed at anytime by the contracting officer or 
a designated assistant. 

The first form letter from the report file is initiated 
upon the assignment of the CS. The contracting officer 
initiates a letter to the customer informing him of the 
acceptance of the contract request, the CS assigned, the 
contract number and also the need for a complete SOW and 
government estimate (if the customer is the engineering 
department, otherwise the CS will ensure that the government 
estimate is developed) . The basic form of the letter is 
contained in a report generator file. This file is a collec- 
tion of all the reports and letters required during the 
entire contract process. The user is given the option when 
using the form letters/reports to input the information 
using a word processor type entry or to let the system 
extract the information from the various databases in the 
system. For example, the letter to the customer can obtain 
the contract number and the CS assigned from the contract 
file. The contracting officer needs only to' identify the 
correct contract file. 

C. DEVELOPMENT OF STATEMENT OF WORK (1.3) 

The SOW may be written by the customer using a word 
processor and transmitted to the contract office via modem 
or by sending a copy on a floppy disk to the CS. The CS can 
proceed to use a word processor to proof the SOW and make 
the appropriate changes then return the SOW to the customer 
in a similar manner. If the SOW is electronically produced 
it can be placed into the contract file. If not, a duplicate 
physical file will have to be maintained for any 
non-electronically produced documents. 
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D. DETAILED GOVERNMENT ESTIMATE (1.4) 



An application module maintained by the contracting 
staff will be available for use by the engineering staff to 
develop the estimates. The module will permit the estimator 
to access a database of standard costs for various labor 
categories. A cost estimate worksheet will be provided the 
estimator from the reports/letters file which permits the 
estimator to build the estimate from the labor costs data- 
base. The estimator application module allows the estimator 
to enter a labor class and estimated effort from which the 
total cost for that labor class will be calculated. The 
module will supply the current applicable overhead, G?A, and 
other fees and calculate the bottom line figures. The esti- 
mator is provided the flexibility to change any estimate 
entered and reguest another calculation of the total. The 
estimate can then be electronically transmitted to the C3 . 

E. REQUIRED CLEARANCES AND APPROVALS (1.5) 

Based on the provided government estimate, the • CS can 
utilize a rule-based decision module to determine which 
clearances and approvals are required for the procurement 
action. The ruled-tase is maintained by the contracting 
staff to reflect current contracting regulations. The CS 
would be guided through a series of possible requirements. 
If the module determines a clearance or approval is 
required, the CS determines if the report or letter should 
be prepared. If the report/letter is to be prepared, the 
report/letter file is accessed for the proper format and the 
information required can be obtained from the various data- 
bases or alternately may be provided by the CS. In the 
former case, the CS will be prompted for the information and 
be given the format for the information if a specific format 
is required. Copies of any correspondence will be placed in 
the contract record data file. 
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F. S MALI BUSINESS SET ASIDE RECOMMENDATION (1.6) 

This recommendation will be a part of the rule-based 
module described above. Once the decision is made, the 
contract file will be updated to reflect the decision. 

G. CCMMERCE BUSINESS DAILY SYNOPSIS (1.7) 

The CS will call up from the report/letter file the 
format for the letter to the Commerce Business Daily. The 
basic form such as the address and standard verbiage will be 
on the letter. The CS using a word processor can fill in the 
body of the letter with the information concerning the 
proposed contract then print a hard copy and mail it to the 
CBD. A copy of the CEE announcement letter will be placed in 
the contract file. 

H. LOGGING OF SF 254 AND SF 255 (1.8) 

The SF 254/255 provides information on the contractor 
and the firm’s history of performance. The CS or a staff 
assistant will enter the summary information from the forms 
into the Contractor Information System (CIS) database. The 
application module permits a number of functions to be 
performed on the CIS database. These include adding, 
changing, deleting, viewing and printing of reports. A 
sample of an operational CIS application module is presented 
in Appendix A. An important aspect of the design of this 
application module is the data design and description. The 
Contractor Information System is a NAVFAC system included as 
part of the NFS. The data collected in this module must be 
as near as possible to the data format and descriptions as 
used in the NFS. This compatibility will insure that when 
future transmission of information between the EFD or FACSO 
becomes a reality, there will be minimal interface problems 
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and adjustments. The details of the CIS are discussed in the 
Appendix A. 

The CS or contracting officer can use the CIS for devel- 
oping bidder’s lists for specific contract r eguirements. 
This is especially important to have in the advent of urgent 
design projects which must be accomplished under exceptional 
circumstances. Contractors who have previously submitted the 
SF 254 need not be reentered into the CIS. Their file will 
only require updating. Under normal conditions, most 
contracting offices have a stable base of contractors who 
continuously bid on contracts. This reduces the number of 
first time entries into the CIS. 

I. BOARD APPOINTMENT LETTERS (1.9) 

A database is maintained listing the eligible board 
members and the current boards they are sitting on as well 
as the last concluded board they sat on. _ A board member 
selection module will permit the selection of the members 
from the list simply by indicating an identifier (number or 
letter). The module will then access the reports/letters 
file and extract the notification letter for the board 
members. The letters will be printed out automatically or 
transmitted to the member's office if electronic mailing 
systems are in use. The contract file will be automatically 
updated to indicate the pre-selection board members. 

J. PRE-SELECTION (1.10) 

The reports/letters file contains a form pre-selection 
board letter. This form letter can be used by the Board to 
record the Board meeting results. The CS upon receiving the 
results of the board and an authorized signature ccpy of the 
board report will update the contract file with a copy of 
the board report. 
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All during the pre-negotiation phase the contract 
tracking system has teen operational. The updates to this 
tracking system can either be performed automatically by the 
master module of the contracting HIS or by the CS as the 
steps are completed. This tracking system is carried through 
to the Negotiation Phase. 



64 



VII. automation of the n ego tiation phase 

Transition to tie second phase of the A-E contracting 
phase from the first phase is transparent to the user. The 
same proposed tracking system, databases and the reports/ 
letters file are used. In fact the main driver program for 
the application modules is still in use. 

A. INTERVIEW LETTERS (II. 1) 

The pre-selection board report produced the slate of 
contractors to be considered in the interviewing process of 
the negotiation phase. The names of these contractors were 
placed in the contract file as the closing action of the 
first phase. The CS can retrieve the form interview letter 
from the reports/letters file. The contractors names can be 
extracted from the contract file. The addresses of the 
selected contractors can be extracted from the CIS database. 
The CS will more than likely schedule the interviews around 
the availability of the board members and the contractors. 
Cnee a schedule has been established, the CS will note the 
times and place of the interviews, print the letters and 
send them to the contractors. A schedule of the interviews 
will be maintained in the contract file. 

B. INTERVIEW OF THE A-E FIRMS (II. 2) 

Several items can be included in this step of the 
process but all the automated options are at the discretion 
of the contracting officer. A form interview evaluation 
sheet can be maintained in the reports/letters file. This 
type of uniform evaluation focus can ensure that all the 
board members evaluate the proper aspects of the contractor. 
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This form would be used in conjunction with the predefined 
evaluation criteria. The evaluation would be a standard form 
used for all contract interviews. A listing of instruction 
to the interviewers can also be prepared and maintained in 
the file. If a standard evaluation algorithm is used by the 
board to determine the best qualified contractor, a module 
can be provided to calculate the results. While this would 
provide an analytically determined best qualified 
contractor, it is probably only a good starting pcint for 
discussion by the selection board. 

C. SEIECTION OF A CCKTRACTOR (II. 3) 

Once the board determines from the interviews who the 
best qualified contractor is, a board report must be 
produced for approval of the selection. Again the CS or the 
head of the board can retrieve a form letter from the 
reports/letters file. The heading and boilerplate informa- 
tion will already be cn the letter and the CS can use a word 
processor to fill in the remainder of the letter based on 
the findings of the board. After the selection has been 
approved by the approval authority, the contract file will 
again he updated by the CS. 

D. REQUEST FOR FEE PROPOSAL (II. 4) 

The selected contractor is supplied with a standard 
government estimate form. This ensures consistency between 
the format of the contractors estimate and the government 
estimate. The estimation form and the letter to forward the 
form to the contractor are both contained in the reports/ 
letters file. The CS can add any instructions and comments 
that are deemed appropriate for the particular contract. 

If the contract is of sufficient size, various forms and 
certificates will be required of the contractor. A 
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rule-based module will again be employed to assist the CS in 
determining which forms and certificates are required of the 
contractor. The module will automatically retrieve any 
required forms and will also signify which certificates are 
necessary. 

E. RECEIPT OF THE FEE PROPOSAL (II. 5) 

Once the fee proposal is received by the CS, the 
contract file is updated to show the receipt. The lead engi- 
neer (on the board) will review and compare the estimates. A 
spreadsheet type module could be developed for use in this 
comparison process. The module would evaluate the differ- 
ences in particular items on the estimates. This however is 
not recommended since in most instances the estimates will 
vary in the classes of labor that will be used. It would be 
comparing dissimilar items which is no comparison. The 
expense of. development and the overhead of maintaining such 
a module probably could not be justified. 

The amount of the fee may require that other clearances 
be obtained. A rule-based module will again be used to 
assist the CS in identifying the clearances needed. If forms 
are needed they will be produced along with a forwarding 
letter to the contractor. 

F. P RE- NEGOTIATION (II. 6) 

No automation is needed in this step except for possibly 
the writing of memorandums using a word processor. The 
letter would be a record of any pre-negotiation discussions 
the CS or engineers have with the contractor. These 
documents would be filed in the contract file. 
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G. NEGOTIATION BOARD MEETING (II. 7) 



The negotiation hoard report form letter is maintained 
in the reports/letters file. The CS, upon completion cf the 
negotiations with the contractor and agreement between the 
hoard members, will prepare the board report using a word 
processor to fill-in the form letter. The letter would then 
he forwarded to the approval authority for signature. 

H. NEGOTIATION BOARD REPORT APPROVAL (II. 8) 

Since this function occurs outside of the contracting 
office in most cases, no automation is required. However, if 
electronic mail is in use, the letter can be sent through 
this system. Signatures in an electronic mail system can be 
implemented through the use of specially assigned password 
type keys. For example, unique control sequence entries into 
the designated signature block of the letter can be recorded 
but not seen. The tail or head of the control sequence can 
contain the visible initials or name of the person whose 
unseen signature is present. A module can be used in the 
system tc decipher the signature for verification purposes. 

I. CONTRACT AWARD (II. 9) 

The approved contract award report is filed in the 
contract file. This step requires the CS to build the 
actual contract by using an on-line file of standard provi- 
sions and special previsions. The CS can place all the 
required contract documentation in a single working file and 
upon completion have the the contract printed. The 
contracting office ccpy of the contract need not be printed 
since it will be placed in the contract file and can be 
reviewed at any time hy the contracting staff. The complete 
contract can then he forwarded to tne contractor for 
signature. 



68 



VIII. AUTOMATION OF THE POST^AWAHD PROCESS 

The end of the second phase is also the end of the 
proposed tracking system used in the first two phases. A new 
proposed tracking system is initiated at the beginning of 
the third phase of the A-E contracting process which is 
similar to previous one with the exception being the things 
that are tracked. The tracking database contains the 
project number and title (relating to any special project 
designs that are being accomplished), contract number, A-E's 
name and number, fee for the design, current working esti- 
mate, engineer in charge of the design effort and the award 
date of the contract. Dates to be tracked are the scheduled 
and actual submittal dates for the 3055, 60%, 90%, and 100% 
from the contractor as well as the comparable dates for the 
government review process of the contractor's work. 

This tracking system is initiated by the CS with the aid 
of a module which actually creates the database from 
existing databases and the contract file once the CS signi- 
fies which contract is to be tracked. The tracking system 
can be used by the contracting officer or the CS tc see 
which actions are required to be completed on a certain day. 
The system also provides a profile of the actions due for 
completion over a specified period of time. This feature 
will be most helpful at peak operating period such as the 
end of the fiscal year. 

A. NOTIFICATION LETTERS (III. 1) 

The CS utilizes the reports/letters file to retrieve the 
notification letter format. In most cases, this letter is 
completely standardized with the only information tc be 
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added being the names of the receiving contractor and the 
contractor who was awarded the contract. The CS can either 
put these in using a word processor or the system can 
perform this automatically by the CS indicating which 
contractor was awarded the contract. The remainder of the 
information can be obtained from the contract file where all 
the considered contractors names and addresses are listed. 
Copies of these letters are not retained but a notation is 
made in the contract file that the letters were sent. 

B. INDIVIDUAL PROCUREMENT ACTION (DD FORM 350) (III. 2) 

The DD 350 reports to higher commands information 
concerning individual procurements. It is to be submitted 
the day after a contract has been awarded. An application 
module is provided to permit the CS to supply the informa- 
tion for the completion of the report. The format for the 
interface with the module can take on many forms depending 
upon the design of the system. One interface would be for 
the CS to be prompted for the information that is not 
already available in the contract file or the Contractor 
Information System database. For information which already 
exists the CS can verify the correctness. Once the informa- 
tion is gathered, a standard format can be used from the 
reports/letters file to print the form. An enhancement would 
be to transmit the form electronically to either the EFD or 
to NAVFAC directly if the communication resources are in 
place. A copy of the report would be placed in the contract 
file . 

The DD Form 1057 is a monthly summary of contracts 
awarded by the activity. A similar procedure can be used by 
the contracting staff to produce this report. As systems 
evolve, reports such as the DD 350 and 1057 will become 
obsolete. The information required by the EFD and NAVFAC 
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will be available to these upper levels of command at all 
times. Communications and networks will exist such that the 
application modules to retrieve the information currently 
provided by these reports will reside at the level where the 
information is required. These modules will be able to 
access specially designated databases at the field levels 
whenever the data is desired. 

C. OTHER EEPOETS (III. 3) 

As mentioned in the other two phases, rule-based appli- 
cation modules will determine which reports are required for 
the individual contracts. These modules will indicate the 
required reports and guide the CS in preparing them for 
submission. The report formats themselves will reside in the 
reports/letters file. Any reports submitted will be filed in 
the contract file. 

D. DISTRIBUTION OF CONTRACT (III. 4) 

Copies of the contract will be sent to various parties. 
If the parties to receive the copies have electronic mailing 
systems, the copies can be sent this way expediting the 
mailings and reducing the mailing costs as well as aiding in 
the storage of such documentation at the receiving end. Many 
EFDs require a copy of each contract awarded so information 
can be obtained for reference purposes. This procedure may 
change in the future as the information transfer 
possibilities are expanded. 

E. CCNTBACTOR MEETINGS (III. 5) 

These meetings may occur for a variety of reasons and 
all should be documented. The engineer or the CS could use 
the word processor to record the events of the meeting. A 
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copy of the meeting minutes will be placed in the contract 
file. Seme contracts, especially those with a first time 
contractor, require a preliminary meeting to discuss stan- 
dard administrative items. Checklists to cover the require- 
ments cf the meeting can be maintained in the 
reports/letters file for use by the CS or engineer as a 
guide for the meetings. 

F. DESIGN BEVIEWS (III. 6) 

The tracking system is the key management tool in this 
procedure. Other valuable computerized tools would be a 
database of the assigned drawing numbers. This would permit 
the recording of the drawings numbers and titles. This data- 
base could be expanded to act as an index for future refer- 
ences to the location cf drawings which would be useful to 
the larger engineering departments. The documentation which 
accompanies the review process (comment sheets on submit- 
tals) can be maintained in their basic form in the reports/ 
letters file. 

G. CCNTBACT MODIFIC ATIONS (III. 7) 

Contract modifications are not tracked on the third 
phase tracking system. A note is made on the tracking system 
that a modification is taking or has taken place. It is 
proposed that a separate tracking system be established for 
these modifications. This modification tracking database 
would contain many of the data elements that the phase I and 
II system tracked including a brief description of the modi- 
fication, contract number, dates (estimated and actual) for 
SOW and government estimate submission, request for and 
receipt cf the fee proposal, negotiation board meeting and 
the signing of the change order. The estimated days are 
generated automatically based on past experience. The CS 
will enter the actual days. 
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Beard member appointments and letters of notification 
are required. This is handled utilizing the same modules 
that were used in the earlier phases. The processing of the 
SOW and government estimate are identical to step 1.3 and 
1.4. In essence, this process follows the same procedures 
as are followed in the negotiation phase of the contract and 
requires the same management attention. For open-ended 
contracts, the modification process can be in progress for 
different proposed changes. This requires that management of 
the contract modifications be effective and accurate. 

H. PBOGBESS PAYMENTS (III. 8) 

Management of the progress payment process is most 
important for good working relations with the contractor. 
Even though the contracting office is not the actual payer 
of the funds, mismanagement of the request for payment can 
have damaging effects. A spreadsheet type file is maintained 
for the contract which contains the dates and amounts of 
requested payments as well as the date and amount of the 
actual payments. The payment data may be difficult to 
obtain depending on the arrangements made between the 
contracting office and the paying office. This relationship 
should be established such that the CS can obtain accurate 
information in a timely manner. 

The CS receives the request for payment from the 
contractor. A standard form from the reports/letters file 
will be used by the CS to transmit to the lead engineer the 
information regarding the payment request. The engineer must 
annotate the form indicating his approval of the percentage 
complete on the project. This percentage is used to deter- 
mine the amount of the payment to the contractor. If elec- 
tronic mail is in use, this process can be accomplished 
electronically. The final copy of the engineer's annotated 
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copy is placed in the contract file. The spreadsheet data- 
base is updated on each request. An application module 
performs the calculations on the amounts to be withheld and 
amounts to be paid based on predetermined standards. The 
system then generates the proper form requesting the paying 
activity to pay the contractor the specified amount or 
transmitted electronically to the disbursing agent. 

I. DISPUTES, ERRORS, OMISSIONS, DESIGN DEFICIENCES, A-E 

LIABILITY (III. 9) 

The actual handling of these actions is determined at 
the local level. Boards are often convened to make determi- 
nations. In this case, the modules used to establish board 
members can again be utilized. Also, some reports may be 
necessary in certain circumstances . These reports can be 
maintained in the reports/letters file. All matters 
concerning disputes, errors and omissions, design defici- 
ences, etc. require correspondence. A word processor can be 
used to produce these documents. Copies of any documents 
should be placed in the contract file. 

J. FINAL PAYMENT (III. 10) 

The final payment request is handled in the same manner 
as the progress payments except the contract must be checked 
to ensure that all requirements have been met. The same 
spreadsheet database is used in this process. 

K. CONTRACTOR RELEASE (III. 11) 

The tracking system is used to ensure that all required 
submissions have been made. The lead engineer must also 
provide his approval. The document form is maintained in the 
reports/letters file for the contractor release. A copy of 
the release form is placed in the contract file. 
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I. A-E EEBFORMANCE REPORT DD 1413 (III. 12) 

The form report is contained in the reports/letters 
file. The CS and lead engineer complete the form anc the 
completed form is added to the Contractor Information System 
file. The report is also distributed to the required distri- 
bution. The required distribution listing can be maintained 
with the form. 
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IX. END-USER INTERFACE 
A. END-OSER PERCEPTICHS 

The A-E contract MIS described in the previous three 
chapters is intended to aid the contracting officer and the 
CS in managing and administering the A-E contracting 
process. The end-users of the system, the contracting 

officer and his staff, perceive automated systems and the 
use of computers in different frames of reference. The 
contracting officer, in previous tours or through formal 
schooling, has possibly been exposed to the use of computers 
and possibly programming. The staff members may or may not 
have ever used a computer. The computer to them may be 

perceived to be a threat to their jobs or a new method and 

style cf work. Therefore, there may be resistance to the 

change from a fully manual process to one in which the 
computer is an integral part. 

Users judge and accept a system on the basis of their 
personal experience with it. If the system is easy to learn 
and use then it is normally accepted and becomes a useful 
tool. On the other hand, if the system is threatening and 
difficult to use they will probably not use it. This can 
cause extreme problems if the previous methods of performing 
the work tasks are being replaced with the automated 
process. Larson [Ref. 9: p.2] identifies the following 

factors as affecting the end-user's perception of a computer 
system: 

Time. How long dees it take the end user to perform his 
task? 

lear nin g. How long does it take a novice to learn the 
system? 



76 



Recall. How easy is it for an end user to recall hew to 
use the system after he has not used it for some time? 

Vers atilit y. Can the system be used to perform a 
variety of tasks that the end user faces? 

Errors. How many errors does the end user make and how 
serious are they? 

Help. Does the system provide help when the end user 
has trouble? 

Adaptab ili ty . Does the system adjust to the end user’s 
level of competence as he becomes more experienced? 
Does the system tailor itself to the habits and styles 
cf different users? 

Concent rat ion. Hew many things must an end user keep in 
mind while using the system? 

Fatigue. How guickly does the user tire while using the 
system? 

Un if ormity ♦ Are the commands of this system identical 
to equivalent commands of other systems? 

Fun. Does the end user enjoy the system? 

Chapters 6-8 described various automated tools which can be 
used in the three phases of the A-E contracting process. The 
design and development of these tools could be excellent but 
if the end-user has difficulty in understanding or using the 
tools they are useless. End-user interfaces must be designed 
into the system to ensure the above factors are satisfied. 
Failure to satisfy them can result in the users not using 
the system or not gaining the full benefits from the use of 
the system. 

E. SCREEN DESIGNS 

The A-E contracting HIS must be designed to permit the user 
to perform the contracting process tasks in a smooth manner. 
A major element in achieving this is the structure of the 
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system and how it is configured. This will be described in 
the following chapter. The second element to this achieve- 
ment is the design of the methods by which the user is 
"guided" through the system. These methods include the use 
of menus, prompts, information presentation, data presenta- 
tion, text presentation, messages and replies, and help 
facilities [Bef. 10: pp. 19-21,34,36-37 ]. 

1 . Menus 

Menus present the user with a number of choices, the user 
keys in his choice and the system moves on. Menus can 
present any number of choices, however as the number 
increases so does the confusion of the user. Menu options 
should be limited tc as small a number as possible. As an 
example consider the main menu used in the Contractor 



MAIN MEND 



A) 


Add a 


record 


D) 


Delete 


a record 


E) 


Exit ( 


work completed 


H) 


Help 




P) 


Print i 


a report 


Q) 


make a 


Query 


U) 


Update 


a record 


V) 


Vi ew a 


record 


option: _ 





Figure 9.1 Contractor Information System Main Menu. 

Information System, Figure 9.1. This menu offers the user a 
selection of all the possible options and features available 
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under the CIS application module. The user knows by the 
names used for the options what can be performed by using 
this module. The options are listed in alphabetical order 
where the option selection keys, (A, D, E, H, P, Q, U, and 
V) , correspond to the key word of the option. If more than 
nine options are necessary, it is better to divide the menu 
into two separate menus, chaining them together. 

2 . Pr o mpt s 

Erompts are text on the screen identifying the type 
of information that the system desires the user to enter. In 
simple terms, they are just questions and answers. At the 
conclusion of entering a new record into the CIS database 
the user is ask, "DO YOU WANT TO INPUT ANOTHER RECORD? (Y OR 
N)". The system waits for a response from the user before 
any other action takes place. 

Prompts can also take the form of screen overlays 
which show the format for the entry of data. Figure 9.2 is 
the data entry format used to add records to the CIS data- 
base. In this approach, the cursor appears at the first 
entry point. Contractor Number, for the entry of the first 
data. Only four digits are permitted for the contractor 
number. This limitation is shown by the number of blank 
spaces in the prompt. Rather than using blanks, reverse 
video highlights the entry areas and limitation on the allo- 
wable data entry field length. Reverse video is not provided 
on all terminals. After the user has entered the first data, 
the cursor jumps to the next data entry area. Phone. The 
user can move back to a previous data entry area to change 
data if required. Methods for this movement between data 
areas is dependent upon the hardware utilized. The cursor 
continues to move to the next data entry area until all the 
data has been entered for this screen. The CIS requires two 
screens to input all the contractor information. The 
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completion of the last data item. Fee for project 3, will 
automatically call the next screen up for the user to 
complete. If any data item is not known or not applicable, 
the entry area can be skipped by pressing the return key. 

The entry screens should call for the information as 
it appears on the source documents. This will permit the 
user to go through the source document smoothly rather than 
jumping randomly over it. Crowding too much on one screen 
makes the entry process difficult. There should be space 
between each data entry area. 



CONTRACTOR DATA FILE 

Contractor Number - Phone - ( ) - 

Contractor Name - 



Street or P.O.Box - 

City - State - Zip - 

PROJECT HISTORY 

Project 1 - 

Fee - “ - - - 

Project 1 ~ _ 

Fee - _ 

Project 3 - 
Fee - 



Figure 9.2 Data Entry Screen for CIS. 



3 • Inf ormati on P resentation 

Information presented to the user should be in a 
usable form. For example, the tracking systems for all the 
contracting phases require the entry of several dates by the 
user. The dates should always be asked for by the system in 
a form that is normally used by the user (i.e. DD/MM/YY, 
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MM/DD/YY or even May 18, 1984). These forms are common to 

everyday use. While these forms are easiest for the user, 
the julian date system is more practical for use in computa- 
tions undertaken by the computer. The input from the user 
in one cf the above forms can be easily converted to a 
julian date by the computer. Likewise the output or presen- 
tation of the information to the user should be in a 
normally acceptable form. The computer should convert any 
internal data format to a readable format for the user. The 
user should never have to rely on a coding scheme to 
decipher information presented by the computer for his use. 

4 . Data Presen tation 

Data presentation concerns the display of non-native 
language iEformation on the screen. Most of the information 
presented in the proposed A-E MIS is in a readable form. 
There could be applications which would list cost data along 
with cost category codes or contractor numbers. The data 
should be identified by titles or headings of some sort. 
Displays such as 47528052347654, where 4752 is the 
contractor number and (805) -234-7654 is the contractors 
phone number, make no sense to the normal user. An example 
of acceptable data presentation is the Contractor Discipline 
Profile screen shown in Figure 9.3. The main body of the 
screen displays the discipline codes and the number of 
personnel are in the discipline category. The discipline 
codes are numeric as are the count of personnel in the 
categories. Each code and count number are separated and the 

definition of the code is listed (i.e. 10 25 Civil Eng 

indicating there are 25 persons in discipline category 10 
which is Civil Engineers). 
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CON 1EACT0R DISCIPLINE PROFILE 


Contractor 

Contractor 

Discipline 


Number - 

Name - 

Code - Number of 


Personnel 


— 


0 1 


24 


Administrative 


02 


20 


Electrical Eng 


03 




Oceano grahers 


04 


— 10 


Architect 


05 




Estimators 


06 




Urban Planners 


07 




Chemical Eng 


08 




Geologists 


09 


~ 3 


Sanitary Eng 


10 


”25 


Civil Eng 


1 1 




Hydrologists 


12 




Soils Eng 


13 




Construct Insptr 


14 


B 


Inter. Design 


15 




Spec Writer 


16 


TT2 


Draftsman 


17 




Landscape Arch 


18 




Structural Eng 


1 9 




Ecologists 


20 


ITT 


Mechanical Eng 


21 


IT™ 


Surveyors 


22 




Economists 


23 




Mining Eng 


24 




Transport Eng 


25 
— > 


DC YOU 


General 

WANT TO INPUT ANOTHER 


RECORD 


? ( Y or N ) 



Figure 9.3 CIS Contractor Discipline Profile Screen. 

5 • Text Pre se n t ati on 

It is often necessary" to give instructions or 
present information in the form of text. For reading ease, 
the text should be in upper and lower case. The text should 
be presented in short sentences, allowing enough space 
between paragraphs sc as not to crowd the screen. If neces- 
sary, use more than one screen to display the information 
rather than crowd toe much on one screen. Figure 9.4 illus- 
trates these concepts. The instructions appear in the 
module used to view contractor data. The instructions are 
brief and to the point. Since there is more information than 
can be presented on one screen, two screens are used. The 
user can scroll to the second screen by simply hitting any 
key. The browsing instructions given on the second screen 
also appear on the data screens in an abbreviated form. 
Simplicity and under standability are the key elements to be 
followed . 
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♦♦SCREEN 1** 

To view a specific contractor's data record you need 
to know the contractor number. 

If a specific number is not used you will begin with 
the first record. The records are arranged in 
alphabetical order by contractor name. 

You can also just browse thru the records. 



PRESS ANY KEY TO CONTINUE 



♦♦SCREEN 2** 



The following options are available in browse: 

B)ack--Takes you to the previous record. 

F) orward — Takes you to the next record. 

P) rofile — Displays the Discipline Profile. 

of the contractor. 

N) umber — Permits you to locate a contractor 
by the contractor number. 

Q) uit — Returns you to the main menu. 



Do you need to see a listing of the contractor numbers? 



Figure 9.4 Text Presentation in the CIS Module. 



6. Messages and Re plies 

Communications that emanate from the computer to the 
user form a direct psychological link between the user and 
the computer. These communications give the computer some 
human-like gualities that tend to be perceived to threaten 
the user. Like conversing with an individual, the computer 
should never produce a blank screen. This lack of feedback 
often gives the user a feeling of being lost. If a process 
is being carried out which reguires more than 3 seconds, it 
is best to provide a message to the user that a process is 
taking place. In the CIS module, the initialization of 
memory variables requires approximately 10 seconds. During 
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this tine, the user is presented with a sign-on screen 
display as shown in Figure 9.5. The display of the screen 
does not make the initialization process go any faster, but 
the user is told of. the time requirement and exactly what is 
going on. 



NAVFACENGCOM 

Contractor Information System 



A Hie ic-Processor Application 
of 

FACSO’s CIS 



Developed by: 

TOH ETHIRIDGE 

SPRING QUARTER 1984 
NAVAI POSTGRADUATE SCHOOL 



Wait 10 seconds for system initialization to complete. 
> Press any key to continue < 



Figure 9.5 CIS Sign-on Screen Display. 

The most valuable messages in terms of system 
control and protection are error messages. They inform the 
user of mistakes or the failure to comply with system 
imposed constraints such as data formats. Error messages 
should be concise and yet provide enough information for the 
user to recover from an error. Verbosity and error messages 
do not go together. Rhen possible, the error message should 
permit an escape for the user. Figure 9.6 is an example of 
an error message used in the delete module of the CIS. This 
message appears when the user requests to delete a 
contractor record that does not exist in the file. The user 
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is told that the contractor record does not exist. Then the 
user is given an option or an escape. The user is not left 
wondering what should be done. 



That contractor number is not in the file. 



Do you want to: 

1) Try again or, 

2) Return to mam menu. 



Figure 9.6 Sample Error Message. 



7 • Help Fa cilit ies 

On-line help facilities are an advantage if they can 
provide information for the user in a capsulated form. If 
extensive helps are required they should be provided in the 
user’s manual. Concise helps or memory aids can save the 
user the effort of having to continuously go to the refer- 
ence material. For a large diverse system it is best to 
design the help facilities such that they reside in the 
modules in which they are needed rather than in cne large 
separate module. A menu of help information should be 
presented where the user can choose the desired help. 

C. INTERFACE TRADE-OFFS 

All the interfaces described in the above paragraphs are 
included in the system to improve the "f r iend li ness" of the 
system. These aids to system use require storage space in 



85 



memory as do the application modules and data. There has to 
be a limit to the aids provided in order to balance the 
storage requirements. Consideration must be given tc the 
number of help facilities and the amount of information 
contained in each. The other trade-off to be considered is 
the time response cf the system when a large number of 
interface aids are provided. These problems of storage are 
being overcome by the current advances in storage 
technologies. 



86 



X. SYSTEM INTEG RAT ION 



Chapters 6 through 3 presented a proposal for an auto- 
mated approach to the management of the A-E contracting 
process. The last chapter stressed the importance of the 
interface between the user and the automated system. This 
chapter will present the system components in a MIS frame- 
work and explore the hardware and software aspects to be 
considered for i nplementa tion of the MIS. 

A. OVERVIEW 

In Chapter 5, a MIS framework was described as an inte- 
grated system for providing planning, operation, and control 
of a management function. The proposed A-E automated 
tracking and management system presented earlier fits best 
into this framework as shown in Figure 10.1. The functions 
of the databases, repcrts/letter file, contract files, and 
application programs are integrated to form the A-E MIS. 
The user accesses the MIS through the use of a workstation 
equipped with a keyboard for data entry, a CRT for viewing 
system responses and dialogue screens, and a printer 
utilized to produce hardcopy printouts of reports, letters, 
and schedules. The user interacts with the MIS at the 
highest level through the supervisory program. This 
program, through menus and user friendly prompts, permits 
the user to select one of the functions or applications 1 
available for use. After a selecting of one of the func- 
tions, control of the MIS shifts to that function, meaning 
that the user interacts directly with the function. This 



J A complete listing of the application 
repoxts/letters file, contract files, ana databases 
for the A-E MIS can be found in Appendix B. 



programs 

propose 
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level cf control is below that of the supervisory program in 
a manner that when the user completes the use of the 
selected function, control always reverts back to the super- 
visory program. Application programs normally consist of 
several modules much like the CIS application program listed 
in Appendix A. During execution of an application, control 
may be passed to any cf the modules. But, just as with the 
supervisory program, when the modules* process is complete, 
control returns to the main module of the application. 

Once the user has access to a particular application, 
other functions of the MIS come into play. The application 
program may call or access one of the databases, a form 
report/letter from the reports/letters file, a contract file 



88 



or any combination of these functions- As mentioned above, 
when the user is finished with the application or function, 
control returns back to the supervisory program where the 
user can activate another application or simply leave the 
system. 

B. DATA DICTIONARY 

A subsystem not shown in Figure 10- 1 but which plays an 
important role in the useability of the HIS is the data 
dictionary. The data dictionary is documentation of the data 
items included in the databases together with their rela- 
tionships with other data and programs or routines that use 
them. The major purpose of the data dictionary is to aid in 
the consistency of the HIS data. It normally contains data 
field definitions (how many spaces are permitted for a data 
element) , data definitions (what is and is not included in 
the data element) , and comment information to explain any 
ambiguities in the data elements. Data dictionaries can 
contain explanations cf any restrictions on data, enforce- 
ment measures utilized by the database (error checking for 
data entry) , or modules for monitoring the usage of data. . 
The data dictionary can be either in hardcopy form such as 
[Ref. 6], or be available on-line. In most cases, it is best 
to have hardcopy documentation of the data dictionary with 
an abbreviated form available on-line since microcomputer 
systems normally have limited storage capability. This 
constraint will vary from system to system and will become 
less and less a constraint as storage technology advances. 

C. I BP1EMENTATION OF THE MIS 

The concepts proposed in the previous chapters have been 
based on the idea that the field activities need the ability 
to manage and control their functional responsibilities 
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through the use of existing computer technologies. The hard- 
ware and software required to implement the proposed A-E 
MIS, as well as any ether small activity management systems, 
currently exists on the commercial market. The A-E MIS is 
suitable for operation on most business microcomputers being 
used today. The micr ccomputer has several advantages over a 
larger system for this application, of which the first is 
cost. Mcst micro-based systems can be purchased for less 
than $5,000 and many less than $3,000. The second is that 
technologically better computers are produced at a lower 
cost while at the same time the amount of storage capacity 
built in them drastically increases. The standard business 
micro-computer in 1983 had 192K to 256K of internal memory 
with normally dual 300K to 400K floppy disk drives providing 
the user with 600K tc 800K of easily accessed memory. In 
1984, micro-computers are equipped with the same amount of 
internal memory but with a greater than tenfold increase in 
storage memory of 10 Megabytes. In 1985, micro- computers 
are projected to provide 512K of internal memory and 
possibly 205 Megabytes of storage memory. In the next few 
years, it is projected that read only laser disk storage 
providing up to 4 gigabytes of read only storage will be 
available. All the storage memory devices will be located 
within the actual micro-computer frame. Existing microcom- 
puter can be upgraded to take advantage of the advances in 
storage memory. A third advantage of the micro- computer is 
its ability to be easily adapted to the organizational 
management style. The size and cost of the micro- computer 
permits management to place the computing power on the desk 
of those who need it. 

Commercial software products are available which provide 
the facilities necessary to implement the proposed A-E MIS. 
These application products can also be used by the aggres- 
sive manager to develop personal management tools as well as 
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expand on those proposed herein. The ease of use and the 
high level orientation of these products make the need for 
systems programmers otsolete for the development of simpler 
appl ications. 

The CIS programs listed in Appendix A were developed on 
a Zenith Z-100 2 through the use of two compatible software 
products, dBASE II 3 and ’WordStar'. 4 dBASE II is a database 
management tool that allows easy manipulation of small and 
medium sized databases using English-like commands. WordStar 
is a word processing program. These two application pack- 
ages could be used to develop the entire A-E MIS. Other 
software packages could be used but these two are completely 
compatible taking a major effort of internal system inter- 
facing out of the design effort. The systems should also 
work cn any IBM compatible and a large variety of CP/M 5 
systems. 



2 Zenith Z-100 is a registered trademark of Zenith Data 
Systems. 

3 dEASE II is a registered trademark of Ashton-Tate. 

♦WordStar is a registered trademark of MicroPro 
International. 

5 CP/M is a registered trademark of Digital Research. 
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XI- CONCLUSIONS AND RECO MME N DATIONS 



A. CCNCID SIONS 

For NAVFAC to effectively carry out their mission objec- 
tives, enormous amounts of data are required to be 
collected, organized into logical informational forms, and 
analyzed. Well developed information management systems are 
used to make this possible. The systems utilize! are 
reviewed annually to ensure that they adequately support the 
mission. Systems enhancements are developed and installed to 
further the inclusion of improved technological advances. 

The majority of the computing power used by the NAVFAC 
Naval Facilities System is centrally located in Port 
Hueneme, Ca. at FACSO. The data from field activities is 
collected at decentralized sites (EFDs) and forwarded to the 
central site (FACSO) . The reports utilized for management of 
NAVFAC functions are distributed in hardcopy form to the 
field activities. The major decisions concerning planning 
and requirements definition for the Naval Facilities System 
Plan is centralized at NAVFAC Headquarters. The execution 
and implementation of the plans is centralized at FACSO. 

The current objective of the Naval Facilities System is 
to depart from the wholly centralized approach of data 
processing and to decentralize some system functions 
[Ref. 1: p.5-1]. The initial decentralization is focused at 
the EFDs, Public Works Centers and larger Public Works 
Departments. This is a decentralization of hardware and 
software but not systems development. Development of major 
systems is to remain at FACSO and planning for NAVFAC-wide 
systems will remain at NAVFAC Headquarters. The 
decentralized sites will be able to develop local systems 
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and applications which can effectively improve procedures 
and management. This decentralization is slowly evolving 
down to the field activity level. Some applications have 
teen developed to support field activities, however most are 
presently geared toward collecting and submitting data in 
support of the major NAVFAC data processing systems. 

Several management processes exercised at the field 
activity level could be improved and modernized by the 
development of automated data processing applications. The 
A-E contracting management process is just one of these 
processes. Develop cf applications as described in Chapters 
6-8 is possible as evidenced by the development of the 
Contractor Information System shown in Appendix A. 

Current micro-computer technology will support the auto- 
mation requirements cf field activities since advances have 
greatly increased the secondary storage capacity cf these 
machines. Many application building tools such as word 
processing, database, and electronic spreadsheets software 
are available for development of management systems. These 
tools are at the level that the aggressive manager can 
develop local applications to improve his own management 
techniques and performance.* Micro-computers can easily be 
adapted for transmission of data to other computers as well 
as integrated into local area networks where several micro- 
computer can share applications and computing power. The 
cos t/benef it/performance considerations of micro-computers 
make them excellent tcols. 

E. RECOMMENDATIONS 

The main theme cf the recommendations to be made is to 
take a unified planning approach in evaluating data 
processing for field activities. The recommendations are as 
follows: 
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1. A centralized approach should be taken to identify the 
key needs of the field activities in the area of data 
processing. Orly those functions which are of benefit 
to the majority of the activities should be pursued. 
Possibly subgroups can be identified for secondary 
consideration by those activities affected. 

2. A centralized evaluation and selection of available 
software (word processors, database managers, and 
electronic spreadsheets) should be made to reduce the 
cause of inconsistent applications development. The 
number of permitted software products should be kept to 
a minimum while at the same time permit enough 
diversification to avoid dependence on one vender or 
system. 

3. Similar to 2 above, a centralized evaluation should be 
made of available micro-computers. Limiting the 
selection to not only operating systems [Ref. 11], hut 
alsc to vendors would a-julr. aid in reducing t-e 
proliferation of hardware. 

4. Establish field activity user groups vd- ere 

communications can begin for the purpose of sharing 
ideas, problem solutions, and appl icatior.s . Due to the 
large geographic dispersion of the activities, central 
centers for information exchange should be identified 
(newsletters, regional periodic meetings, software 

exchanges) . 

5. An aggressive approach toward the integration of the 
field activity systems into the MFS will take advantage 
of current technology. The increased sophistication of 
small computer systems and the advances of 
communications software bring these two functions 
closer together. 

6. Incorporate a total system approach to systems 
development to merge the areas of office automation. 
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data processing, and communications technology. This 
should lead to future developments leaning toward 
Information Resource Management. 

7. Institute learning center*, for the purpose of 
exploiting the benefits of micro-computers at the • i*rid 
activity level. These centers could be located at "/“s, 
PWCs, or at the Civil Engineer Corps Officers School n 
Port Hueneme, Ca. 

8. Include in the Kavy Facilities System Plan, Ref. 1, 
long range plans for the development of data processing 
systems for field activities. 

9. Resign and implement the A-E contract management system 
similar to that described in this thesis. The system 
should be field tested, refined and distributed to 
other field activities for use. 
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APPENDIX A 



SAMPLE APPLICATION 



CONTRACTOR INFORMATION SYSTEM 
- A dBASE II PROGRAM - 



The dEASE II ccirmand language has been used to implement a 
contractor information system used by Naval Facilities 
Engineering Command- The system has been designed under the 
following assumptions: 

a) Users of the systems are inexperienced in computer 
usage. 

b) The system should permit facilities tc add, delete 
and browse thru the data. It should also permit any 
persons knowledgeable with dBASE II to use the 
query language on .the database. { This is made 
only under the premise that the system will be 
used by a small group ( 3-4 persons) . It should 
also be pointed that by having access to the 
database that a person can change the database by 
deleting records or modifying existing data. 

c) The system is used by a small group of people. 

d) The database should as much as possible be 
designed to match the database structure of the 
existing NAVFAC database. This will make future 
interfacing with easier. 

Two files are maintained. The contractor data file (caata) 
and the contractor discipline file (edis) . The cdata.dbf contains 
basic demographic information plus a short history of the 
contractor’s work for the USN. The cdis.dbf contains a'breakdown 
of the composition of the contractor's engineering workforce. 
This data is taken from the SF 254 and SF 255. These forms are 
the U.S. Governments contractor resume forms. The Information is 
maintained for future Invitation For Bid mailing lists and also 
for a reference for the Public Works Officer to consult when he 
needs a rapid response design to solve an emergent problem. 

The file structures for the two dbfs are given below. A 
brief data dictionary is also given to aid in defining the fields 
and data elements. 

STRUCTURE FCR FILE: CDATA.DBF 

NUMBER OF RECORDS: 00010 

DATE CF LAST UPDATE: 06/12/84 
PRIMARY USE DATABASE 



FLD 


NAME 


TYPE 


WIDTH 


001 


CNUM1 


C 


004 


002 


CNAME1 


c 


036 


003 


CNAME2 


c 


036 


004 


STPOB 


c 


040 


00 5 


CITY 


c 


021 


006 


STATE 


c 


002 


007 


ZIP 


c 


005 


008 


PHONE 


c 


014 


009 


PROJ1 


c 


050 



96 



010 


FEE1 


C 


006 


011 


PROJ2 


C 


050 


012 


FEE2 


C 


006 


013 


PRO J3 


c 


050 


014 


FEE3 


c 


006 


015 


DELETED 


c 


007 



** TOTAL ** 00334 



CDATA Data Dictionary -+-+->-+-+ 



Field 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 



CNUM1 Contractor number assigned automatically by the 
system. 4 alphanumeric spaces are permitted. 

CNAME1 Contractor name, first line. 36 alpha characters 
are permitted. 

CNAME2 Contractor name, second line. 36 alpha characters 
are permitted. 

STPOF Street address or the post office box. 40 
alphanumeric characters permitted. 

CITY City cf the address. 21 alpha characters are 
permitted. 

STATE state of the address, 2 letter abbreviations. 2 
alpha charcaters are permitted. 

ZIP Zip cede associated with the address. 5 

alphanumeric characters are permitted. 

PHONE Telephone number of the contractor including the 
area code. 14 alphanumeric characters are 

S ermitt ed. 

rief description of the latest project completed 
by the contractor for the government. 50 alpha 
characters are permitted. 

FEE 1 The fee in thousands of dollars paid to the 

contractor for the projected completed above. 

6 alphanumeric characters are permitted. 

PRO J2 Same as PRO J 1 except for second project. 

FEE2 Same as FEE1 except represents PROJ2. 

PROJ3 See above. 

FEE3 See above. 

DELETED Field used to indicate that a record has been 

identified for deletion. 7 alpha characters are 
permitted. 






The edata file is indexed to the file NAMES. MDX by the contractor 
names. A sample of the data in the edata. dbf: 

0000 1 
00002 

00003 

00004 
0000 5 
00006 

00007 

00008 

00009 

00010 



1234 

2345 

3456 

4567 

5678 

6787 

8765 

9065 

7303 

4532 



RE SCOTT BROTHERS DESIGN AND ESTIMATE 
JOHNSON AND JOHNSON ASSOC. INC. 

ABC ENGINEERING 

FIRST RATE GUYS WITH A SLIDE RULE 
ONE MAN ENGINNERING COMPANY 
KEPLER FRANK AND WESPEPPER 
ZEDE PLUMBING AND HEATING 
BROWN ANE ROOT 

DIEBOLD PIPE AND SIEEL ENGINEERS 
WERE YOU THERE 



The CDIS dbf: 



STRUCTURE FOR FILE: 


CDIS 


.DBF 


NUMBER 


OF RECORDS: 


C0010 


DATE CF 


LAST UPDATE: 


06/12/84 


SECONDARY USE DATABASE 




FLD 


NAME 


TYPE 


WIDTH 


001 


CNUM2 


C 


004 


002 


NAD 


C 


004 


003 


NEE 


C 


004 
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004 


NOG 


C 


004 


005 


NA 


c 


004 


006 


NEST 


c 


004 


007 


NOP 


c 


004 


008 


NCHE 


c 


004 


009 


NGE 


c 


004 


010 


NS NE 


c 


004 


011 


NCE 


c 


004 


012 


NHY 


c 


004 


013 


NSOE 


c 


004 


014 


NCI 


c 


004 


015 


NID 


c 


004 


016 


NSPW 


c 


004 


017 


NDMN 


c 


004 


018 


NLA 


c 


004 


019 


NSTE 


c 


004 


020 


NECO 


c 


004 


021 


SHE 


c 


004 


022 


NS UR 


c 


004 


023 


NECN 


c 


004 


024 


NMNE 


c 


004 


025 


NTRE 


c 


004 


026 


NGE 


c 


004 


027 


TOTEMP 


c 


006 


** 1 


TOTAL ** 




00111 



-+-+-4-+-+-+-+- CDIS Data Dictionary 



Field 



1 


CNUM2 


2 


NAD 


3 


NEE 


4 


NOG 


5 


NA 


6 


NEST 


7 


NUP 


8 


NCHE 


9 


NGE 


10 


NS NE 


11 


NCE 


12 


NHY 


13 


NSCE 


14 


NCI 


15 


NID 


16 


NSPW 


17 


NDMN 


18 


NLA 


19 


NSTE 


20 


NECO 



Contractor number assigned by the system 
This is the same number as CNUM1. 

4 alphanumeric characters are permitted. 
Number of administrative personnel. 

4 alphanumeric characters are permitted. 
Number of electrical engineers. 

4 alphanumeric characters are permitted. 
Number of oceanographers. 

4 alphanumeric characters are 
Number of architects. 

4 alphanumeric characters are 
Number of estimators. 

4 alphanumeric characters are 
Number of urban planners. 

4 alphanumeric characters are 
Number of chemical engineers. 

4 alphanumeric characters are 
Number of geologists. 

4 alphanumeric characters are 
Number of sanitary engineers. 

4 alphanumeric characters are 
Number of civil engineers. 

4 alphanumeric characters are 
Number of hydrologists. 

4 alphanumeric characters are 
Number of soil engineers. 

4 alphanumeric characters are 
Number of construction inspectors. 

4 alphanumeric characters are permitted. 
Number of interior designers. 

4 alphanumeric characters are 
Number of spec writers. 

4 alphanumeric characters are 
Number of draftsmen. 

4 alphanumeric characters are 
Number of landscape architects! 

4 alphanumeric characters are permitted. 
Number of structural engineers. 

4 alphanumeric characters are permitted. 
Number of ecologists. 



permitted . 
permitted . 
permitted, 
permitted . 
permitted . 
permitted . 
permitted . 
permitted . 
permitted, 
permitted . 



permitted . 
permitted . 
permitted . 
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21 


NME 


4 alphanumeric characters are permitted. 
Number of mechanical engineers. 


22 


NS OF. 


4 alphanumeric characters are permitted. 
Number of surveyors. 


23 


NEON 


4 alphanumeric characters are permitted. 
Number of economists. 


24 


NMNE 


4 alphanumeric characters are permitted. 
Number of mining engineers. 


25 


NTRE 


4 alphanumeric characters are permitted. 
Number of transportation engineers. 


26 


NGE 


4 alphanumeric characters are permitted. 
Number of general engineers. 






4 alphanumeric characters are permitted. 

+ - + - + -H- + - + - + - 4-- + - + -+-+-+ -+-+-+-+- + 



The command files used in the system are: 

MAIN.CMD SIGN-ON. CMD INIT.CMD 

ADD. C MD DELETE. CMD QUERY . CMD 

VIEF.CMD 

These files are attached in the order that they appear here. 

The format files used are: 

. GETCDATA. FMT GETCDIS. FMT SAYCDATA .FMT 
SAYCDI S. F!1 T VCDATA. FMT VCDIS.FMT 

MAIN. FMT 

These files along with the images they produce are attached. 



Two memory files are used, cdata.men and cdis. mem. These 
files were not printed out. Their structure is inputted in the 
init.cmd file. 

The following pages contain the above mentioned files and 
images. 
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Wain Command Wodule 



version: 

purpose: 



**********$****************$********************** 
♦ main.cmd 6/5/84 j te 

1.0 

sets the main selection screen and perm 
to select which option they would like 
from, processing narrative: the sign-on 
followed by the initialization of the s 
main selection screen is then presented 
terminated selection return the user to 
super ordinate modules: none 

subordinate modules: sign-on. cmd, init.cmd, main 



delete.cmd, view.cmd 



ON 

variables and set the environment 



* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* author: •Tom Etherid<,_ 

*** * * ****** *** ** *** * * ******* * ********************* 

♦display sign-on message 
DO sign-cn 

set console off 

WAIT 

SET CONSOLE 

* 

♦initialize 
EO init 
* 

♦set up the main loop 
DO WHILE t 
♦ 

♦set up screen 
SET FORMAT TO main 
STORE " " TO command 
* 

♦display the main menu 
REAE 
* 

♦perform selected function 
DO CASE 
* 

CASE command = "A” 

DC add 
* 

CASE command = "E" 

DC delete 
* 

CASE command = "E" 

ERASE 

♦ prevent d BASE 11 sign-off msg 
SET CONSOLE OFF 
QUIT 



* CASE command = "H" 

* DO help 
* 

* CASE command = "E" 

* EC print 
* 

CASE command = "Q" 
DC query 

* CASE command = "0" 

* DC update 
* 

CASE command = "V” 
DC view 

ENECASE 
♦loop back 
END DC 



**************** 



its the user 
to operate 
is displayed 
ystem. the 
: all 

the mam menu. 
. fmt, add. cmd. 



* * ** * ** ** ** ** * ** 
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Sign-on Command Module 

****** ** *** ** ** *** ** ***** *************** ** ********* ****** ******** 

* sign-on. crad 6/5/84 

* version: 1.0 

* purpose: to display the sign-cn message 

* processing narrative: the sign-on msg is displayed, control is 

* transferred back to mam.cmd when the 

* user enters a keystroke. 

* superordinate modules: main, crad 

* subordinate modules: none 

* author: Tom Etheridge 

***************************************************************** 

EP.ASE 

NAVFACENGCOM" 

Contractor Information System" 



Developed by:" 

TOM ETHERIDGE" 

SPRING QUARTER 1984" 
NAVAL POSTGRADUATE SCHOOL" 



" > Wait 10 seconds for system initialization to complete <-- 

" > Press any key to continue < " 
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Initiation Command Module 



****:*:*:fc:$c:fc:fc*****:fc:$c*;<c*:$c**:fc**;fc***:$e:fc:fc****:fc**:fc** * *** **$***********$**:$:$ 

* init.cmd 6/5/84 jte 

* version: 1.0 

* purpose: to initialize variables and set the system environment 

* processing narrative: the environment is set up followed by the 

* initialing of the variables used in the 

* add.cmd module, creates cdata.mem and 

* cdis.mem. 

* superordinate modules: main.cmd 

* subordinate modules: none 

* author: Tom Etheridge 

*********************$**:$:****:$:************* ******** ***$************ 

♦run once to initialize the variables and set up the environment 

SET TALK OFF 

SET INTENSITY OFF 

* 



♦initialize the variables 
♦currently set to initialize 
* IF .NOT. FILE ("cdata. mem") 
STOEE " " TO deleted 
STOEE "0000” TO mcnum 
STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

STOEE " 

♦create cdata.mem 
SAVE TO cdata 
♦clear the memory 
RELEASE AIL 



♦END IE 



♦IF . NOT 


m 


FILE < 


'"cdis . mem 


STOEE 


" ! 


0000” 


TO 


mcnum 


STOEE 


11 


11 


TO 


mnad 


STOEE 


if 


11 


TO 


mnee 


STOEE 


ii 


11 


TO 


mnog 


STOEE 


if 


11 


TO 


mna 


STORE 


if 


11 


TO 


mnest 


STOEE 


11 


11 


TO 


mnur 


STORE 


11 


11 


TO 


mnche 


STOEE 


11 


11 


TO 


mnge 


STOEE 


if 


11 


TO 


mnsne 


STOEE 


11 


11 


TO 


mnce 


STOEE 


ii 


11 


TO 


mnhy 


STOEE 


n 


11 


TO 


mnsce 


STORE 


ii 


11 


TO 


mnci 


STOEE 


ii 


11 


TO 


mnid 


STOEE 


11 


11 


TO 


mnspw 


STOEE 


11 


11 


TO 


mndmn 


STOEE 


11 


11 


TO 


mnla 


STOEE 


H 


11 


TO 


mnste 


STOEE 


n 


11 


TO 


mneco 


STOEE 


n 


11 


TO 


mnme 


STOEE 


ii 


11 


TO 


mnsur 


STOEE 


11 


11 


TO 


mnscn 


STORE 


11 


11 


TO 


mnmne 


STOEE 


ii 


11 


TO 


mn tre 


STOEE 


ii 


11 


TO 


mnqe 


STORE 


ii 


11 T0 


answer 



" TO mstate 
" TO mzip 

" TO 

" TO mfeel 
" TO mfee2 
" TO mfee3 



variables 



" TO mcity 



mphone 



during each 



" TO 
" TO 



run of system 



mcnam el 
mcname2 
TO mstpob 



" TO mpr 
" TO mpr 
" TO mpr 
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♦create cdis. mem 
SAVE TO cdis 
♦clear memory 
RELEASE ALL 
♦ END IF 

♦set up the file environment 

SELECT PRIMARY 

USE cdata 

SELECT SECONDARY 

USE cdis 

♦return to main.cmd 
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Add A Contractor Command Module 



* add.cmd 6/6/84 jte 

* version 1-0 

* purpose: to permit the addition of records to the file 

* processing narrative: using the getcdata and getcdis formats 

* data is collected from tne user and 

* placed in the cdata and cdis files. 

* superordinate modules: main.cmd 

* subordinate modules: getcdata S getcdis formats 

* author: Tom Etheridge 

*%**%:%# trbjrb*** ******%$*****&********** jc **#********'£%%%*'$$*$ ***% 

♦set up environment 
SET INTENSITY ON 
♦set up the loop 
STORE t TO more 
DO WHILE more 

♦set up screen for cdata entry 
SET FORMAT TO getcdata 

♦get new set of memory variables for data entry 

RESTORE FROM cdata 

SELECT PRIMARY 

♦let user enter data 

READ 

♦add data to the file 

? " STORING THE DATA ONE MOMENT PLEASE.'’ 

APPEND BLANK 

REPLACE cnuml WITH mcnum, enamel WITH mcnamel 
REPLACE cname2 WITH mcname2 

REPLACE stpob WITH mstpob, city WITH mcity, state WITH instate 
REPLACE zip WITH mzip 

REPLACE phone WITH mphone, projl WITH mprojl, feel WITH mfeel 

REPLACE proi2 WITH mproj2, ±ee2 WITH mfee2, proj3 WITH mproj3 

REPLACE xee3 WITH mfee3 

♦wait for the user response 

♦release all variables 

RELEASE ALL 

♦ set screen for cdis input 
SET FORMAT TO getcdis 

♦get variables for cdis 
RESTORE FROM cdis 

♦pass the contractor number to the cdis file 
STORE cnuml TO mcnun2 

♦ get the cdis data file 
SELECT SECONDARY 

♦let the user input data 
READ 

♦store the data in the cdis file 
APPEND BLANK 

REPLACE cnum2 WITH mcnum2 

REPLACE nad WITH mnad, nee WITH mnee, nog WITH mnog 
REPLACE na WITH mna 

REPLACE nest WITH mnest, nup WITH mnup, nche WITH mnche 
REPLACE nge WITH mnge 

REPLACE nsne WITH mnsne, nee WITH mnee, nhy WITH mnhy 
REPLACE nsoe WITH mnsoe 

REPLACE nci WITH mnei, nid WITH mnid, nspw WITH mrspw 
REPLACE ndmn WITH mndmn 

REPLACE nla WITH mnla, nste WITH mnste, neco WITH mneco 

REPLACE nme WITH mnme, nsur WITH mnsur, necn WITH mnecn 

REPLACE name KITH mnmne 

REPLACE ntre WITH mntre, nge WITH mnge 

♦are there more inputs? 

IF ! (answer) = "Y” 

RELEASE ALL 
STCRE t TO more 
ELSE 

RELEASE ALL 
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STORE f TO more 
EHDIF 

♦loop lack 
ENDDC 

♦set up the index on the names 

SELECT PRIMARY 

INDEX ON enamel TO names 

♦set original environment 

DSE edata 

SELECT SECONDARY 

DSE edis 

SET INTENSITY OFF 
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Delete Command Module 



*************************£****************#************ 
* delete.cmd 6/9/84 jte 
version: 1.0 

purpose: to delete records from the cdata and cdis fi 
processing narrative: local variables are initialized 

is offered a look at the record 
file to determine the contractc 
to delete, the record requested 
user is displayed to verify tha 
be deleted, the record is then 
first the cdata file record the 
file record, if more are to be 
then the loop begins again else 
goes back to the main menu, 
superordinate modules: main.cmd 
subordinate modules: saycdata.fmt 
author: Tom Etheridge 

********************************* 



************ 



les 

. the user 
s in the 
r number 
by the 
t it is to 
deleted, 
n the cdis 
deleted 
control 



*********************5 

♦clear the screen 
ERASE 

♦initialize the local variables 



** ********** 



STORE 
STORE 
STORE 
STORE 
STORE 
♦set 
DO 



t 

ii 



7 

7 

b 



TO more 
11 TO answerl 
" " TO answer2 
" " TO answer3 
"deleted” TO mdeleted 

S the deletion loop 
S more 



7 




7 




7 




7 


ii 


7 


it 


7 




7 


»i 


b 


ii 



To delete records 
contractor number. 



ou need to know the assigned” 

ed" 



a listing of 
and names? ( 



act on it 



numbers and names 



Do you need to see 
contractor numbers 
♦wait for answerl 
WAIT TC answerl 
♦evaluate the response and 
IF !f answerl) = "Y" 

STORE ” " TO answerl 
♦display the contractor 
ERASE 

SELECT PRIMARY 
? " # NAME" 

7 

DISPLAY ALL deleted, cnuml, enamel OFF 

? "PRESS ANY KEY TO CONTINUE" 

WAIT 

ENDIF 

♦aet the contractor number 
ASE 



all the assign^ 
Y or N ) » 



ACCEPT " What 
♦find the record 
SELECT PRIMARY 
SET EXACT ON 
LOCATE FOR cnuml 
♦check for eof 
IF EOF 



is the contractor number?" TO menumd 



= ! (menumd) 
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ERASE 

? "That contractor number is not in the file" 

? "Do you want to:" 

7 

? " 1) Try again or." 

ACCEPT " 2) Return to main menu" TO choice 

IE ! (choice) = "1" 

LOOP 

ELSE 

♦remove the record and compress the file 
PACK 

SELECT SECONDARY 
PACK 

♦return tc main.cmd 
RETURN 

ENDIF 

END IF 

♦display the record to see if it is the correct one 

SET FORMAT TO saycdata 

READ 

♦get the answer 2 
IF !(answer2) = "N" 

STORE " " TO answer2 
LOCP 
ELSE 

♦mark it for deletion 
REPLACE deleted WITH mdeleted 
DEIETE 

♦ get the cdis file 

SELECT SECONDARY 

LOCATE FOR cnum2 = ! (mcnumd) 

SET EXACT OFF 

♦mark the cdis record for deletion 
DELETE 

♦find if we're done 

7 

7 

7 

7 

? " Do you want to delete more records? ( Y or N )" 

WAIT TO answer3 

♦get answer3 

IF ! (answ er3) = "Y" 

♦start over 
STORE " " TO answer3 
LOOP 
ELSE 

♦remove the marked records and compress files 

USE caata 

PACK 

USE cdis 
PACK 

♦end the Iccp 
STORE f TO more 
ENDIF 

♦end answer 2 if 
ENDIF 

♦end the main loop 
ENDDO 
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Query Command Module 

******************************************************* ** ********** 

* query.cmd 6/11/84 jte 

* version: 1.0 

* purpose: to permit the dBASE user to access the command mode 

* processing narrative: the user is told the purpose and 

* requirements of using the command mode. 

* he is told how to return from the 

* command mode to the menu mode. 

* superordinate modules: main.cmd 

* subordinate modules: none 

* author: Tom Etheridge 

****************************************** * * **** * ***************** 

♦clear the screen 

ERASE 

7 

7 

7 

7 

7 

7 

7 

? "This will put you into the dBASE 11 command mode for queries " 

? "of the database. You must know the command language to make " 

? "the queries." 

7 

♦get the response 

ACCEPT "Eo you want to proceed? (Y or N) " TO mquery 
♦analyze the response and act on it 
IF ! (mquery) = "Y" 

ERASE 

7 

7 

? "To return to the menu mode type DO MAIN in the command mode." 
? 

? "Press any key tc continue good luck!!!" 

WAIT 

♦exit menu mode tc command mode 
ERASE 

QUIT TO ‘DBASE B* 

ELSE 

♦return to main. cmd 
RETURN 
ENDIE 
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View Command Module 



* view.cmd 6/9/84 jte 
version: 1.0 

purpose: to browse thru the data 

processing narrative: user is given intro and offered to 

the numbers and the names of the 
contractors, error checking off inputted 
numbers is followed by presenting the 
records either in the indexed order from 
the top of the file or beginning 
specified number, 
superordinate modules: main.cmd 
subordinate modules: vcdata.fmt, vcdis.fmt 
author: Tcm Etheridge 



* 
* 
* 
* 
* 
* 
* 
* 
3fc 
* 



see 



at the 






♦initialize the local variables 

STORE t TO view 

STORE t TO ahead 

STORE " " TO vcommand 

♦clear screen 

ERASE 

♦set the viewing environment 

SELECT PRIMARY 

DSE cdata INDEX names 

SELECT SECONDARY 

DSE cdis 

♦give intro 

•> 



? "To view a specific contractor’s data record you need" 

? "tc knew the contractor number." 

? "If a specific number is not used you will begin with" 

? "the first record. The records are arranged in alphabetical" 
? "order by contractor name." 

7 

? "You can also just browse thru the records." 



? "PRESS ANY KEY TO CONTINUE " 

WAIT 

ERASE 



-5 



7 

7 

7 

b 



"The 



following options are available in browse:" 



7 it 

b ii 
7 ii 
b n 
b ii 
7 n 
7 n 
7 



Black — Takes you to the previous record" 

F' orward — Takes you to the next record" 
Pjrofile — Displays the Discipline Profile" 
of the contractor" 

N) umber — Permits you to locate a contractor" 
by the contractor number" 

Q) uit — Returns you to the main menu" 



? "Do you need to see a listing of the contractor numbers" 
ACCEPT "and names? ( Y or N ) "TO answerl 
♦set loop 
DO WHILE ahead 
♦get answerl 
IF l(answerl) = "Y" 

♦clear screen and show the numbers 
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ERASE 

SELECT PRIMARY 
7 " # NAME" 

7 

DISPLAY ALL cnuml, enamel OFF 

? " PRESS ANY KEY TO CONTINUE " 

WAIT 

ENDIF 

♦ get the user’s desires 



ACCEPT "Do you want to see a specific record? { Y or N ) " TO answe 
IF !jjanswer2) = "Y" 

ACCEPT "What is the contractor number?" TO menumb 
EISE 

♦ if no use the first record 
GOTO TOP 

STCRE cnuml TO menumb 
ENDIF 

♦ set up to check for erroneous data entrv and recovery 
SELFCT PRIMARY 

SET EXACT ON 

IF I (answer2) = "Y" 

LOCATE FOR cnuml = ! (menumb) 

IE EOF 

? "That is not a valid number." 

ACCEPT "Do you need to see the listed numbers again? 

(Y or N) » TO bad 
IF ! (badV = "Y" 

STORE ’Y’ TO answer 1 
LOOP 
ELSE 

? "The first record in the file will be displayed." 

? " — Press any key to continue — " 

WAIT 

GOTO TOP 

STORE cnuml TO menumb 
ENDIF 
ENDIF 
ENDIF 

♦ end the loop 
STORE f TO ahead 

ENDDO 

♦set up the browsing loop 
DO WHILE view 

STORE enamel TO name 
♦set up the screen 
SET FORMAT TO vedata 
READ 

♦evaluate the choice 
DO CASE 

♦check option 
CASE vcommand = "B" 

SKIP -1 

STORE cnuml to menumb 
* 

CASE vcommand = "F" 

SKIP 

STORE cnuml to menumb 
* 

CASE vcommand = "P" 

SELECT SECONDARY 
♦start at the top 
GOTO TOP 

♦find the correct record 
LOCATE FOR cnum2 = ! (menumb) 



♦get the screen ready 
;?t t 



SET FOPMAT TO vedis 
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♦show it 

REAE 

WAIT 

♦restore the main file 
SELECT PHI M ARY 
* 

CASE vcommand = "Q" 

STORE f TO view 
* 

CASE vcommand = "N" 

ERASE 

♦qet the number 

ACCEPT "What is the contractor number?" TO mcnumb 
♦find it 

LCCATE FOR cnum 1 = ! (mcnumb) 

♦is it valid 
II EOF 

GOTO TOP 

? "That number is not valid. Try again.." 

? " Press any key to continue " 

WAIT 

ENDIF 

♦lccp tack 
ENECASE 

♦reset the variable 
STORE " " TO vcommand 
EN E EO 

♦restore the memory 
RELEASE ALL 

♦reset the main environment 
USE cdata 
SELECT SECONDARY 
USE cdis 

♦return to the main menu 
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Main Screen Format 






* 


main. 


f mt 


6/5/84 


jte 






a 


i , 


0 


SAY 


If 




















-- — — " H " 

m 






3 


2/ 


0 


SAY 


TT 


11 

1 11 






MAIN MENU 


3 


3, 


0 


SAY 


TT 








a 




0 


SAY 


11 


1 

1 11 




A) 


Add a record 


3 


5, 


0 


SAY 


ft 


1 

1 tt 








3 


6, 


0 


SAY 


11 


1 

1 ft 




D) 


Delete a record 


3 


7, 


0 


SAY 


11 


1 

1 11 








a 


e. 


0 


SAY 


It 


I 

1 M 




5) 


Exit ( work completed ) 


2 


9, 


0 


SAY 


If 


1 

I 11 








3 


10, 


0 


SAY 


11 


1 

1 11 


£ 


H) 


Help 


a 


11/ 


0 


SAY 


11 


1 

1 >1 








3 


12, 


0 


SAY 


11 


1 

1 It 


* 


P) 


Print a report 


3 


13, 


0 


SAY 


IT 


1 

1 11 








3 


14, 


0 


SAY 


11 


1 

1 I* 




Q) 


make a Query 


3 


15, 


0 


SAY 


If 


1 

1 If 








3 


16, 


0 


SAY 


IT 


1 

1 H 


* 


U) 


Update a record 


3 


17, 


0 


SAY 


11 


1 

1 11 








3 


16, 


0 


SAY 


11 


1 

1 11 




V) 


View a record 


3 


19, 


0 


SAY 


11 


I 

1 11 






*- currently 


3 


20 , 


0 


SAY 


Tf 


I 


Choose an 


option; " 


3 


20, 


28 


GET 


command 






3 


20, 


43 


SAY 


"not ; 


available 


1 


1" 


3 


21, 


0 


SAY 


n l 


1 






22, 


1 








_ "" ""I I" 






a 


SAY 


11 
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Getcdata Screen Format 



J^*************#****************** ##*#**:£******#** £***##*****:$::£*** 

* GETCDATA. FMT 6/5/84 ite 



3 


1/ o 


SAY 


If — 


If 


3 


2, 21 


SAY 


"CONTRACTOR 


DATA FILE 


3 


4, 0 


SAY 


"Contractor 


Number -" 


3 


4,20 


GET 


mcnum 




3 


4,39 


SAY 


"Phone 




3 


4,47 


GET 


mphone PICTURE ' (999) 


3 


6, 0 


SAY 


"Contractor 


Name 


a 


6,18 


GET 


mcnamel 




s 


7, 16 


SAY 


IT _ 11 




a 


7,18 


GET 


mcname2 




3 


9, 0 


SAY 


"Street or 


P.O.Box -" 


3 


9,20 


GET 


mstpob 




3 


llj 0 


SAY 


"City -" 




3 


11, 7 


GET 


mcit y 




3 


1 1 ' 3*7 


SAY 


"State 




3 


11,45 


GET 


instate 




3 


11,54 


SAY 


"Zip 




3 


11,60 


GET 


mzip 




3 


13^ 10 


SAY 


it E _ _ 


PROJECT 


3 


14, 0 


SAY 


"Project 1 


.n 


3 


14, 12 


GET 


mproi 1 




3 


15, 0 


SAY 


"Fee -» 




3 


15; 6 


GET 


mf ee 1 




3 


16, 0 


SAY 


"Project 2 


_ ii 


3 


16, 12 


GET 


mpron2 




3 


17, 0 


SAY 


••Pee — ii 




3 


17, 6 


GET 


mf ee2 




a 


is; o 


SAY 


"Project 3 


— ii 


3 


18, 12 


GET 


mpron3 




3 


19, 0 


SAY 


n£ ee -ii 




3 


19, 6 


GET 


mf ee3 





HISTORY -- 
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Getcdis Screen Format 



************** ****** + ******* ****** *** ********* I***************** 



3 


i. 


0 


SAY 


a) 


2/ 


18 


SAY 


2 


4, 


0 


SAY 


3 


4 , 


20 


SAY 


3 


5, 


0 


SAY 


2 


5, 


18 


SAY 


2 


7, 


0 


SAY 


2 


3, 


5 


SAY 


2 


8, 


8 


GET 


2 


8 , 


15 


SAY 


3 


8/ 


44 


GET 


a 


8/ 


51 


SAY 


3 


9, 


5 


SAY 


a 


9, 


8 


GET 


3 


9, 


15 


SAY 


3 


9, 


44 


GET 


2 


9, 


51 


SAY 


2 


10, 


5 


SAY 


2 


10, 


8 


GET 


3 


10, 


15 


SAY 


2 


10 , 


44 


GET 


3 


10, 


51 


SAY 


3 


11, 


5 


SAY 


2 


1 1 / 


8 


GET 


3 


1 1 / 


15 


SAY 


3 


1 1 , 


44 


GET 


3 


11, 


51 


SAY 


3 


12, 


5 


SAY 


3 


12, 


8 


GET 


3 


12, 


15 


SAY 


3 


12j 


44 


GET 


2 


12, 


51 


SAY 


3 


13, 


5 


SAY 


3 


13' 


8 


GET 


a 


13, 


15 


SAY 


3 


13, 


44 


GET 


3 


13, 


51 


SAY 


3 


14, 


5 


SAY 


3 


14, 


8 


GET 


3 


14, 


15 


SAY 


2 


14, 


44 


GET 


3 


14 , 


51 


SAY 


2 


15, 


5 


SAY 


3 


15, 


8 


GET 


2 


15, 


15 


SAY 


3 


15, 


44 


GET 


3 


15, 


51 


SAY 


2 


16, 


5 


SAY 


3 


16, 


8 


GET 


3 


16, 


15 


SAY 


3 


16, 


44 


GET 


3 


16, 


51 


SAY 


3 


17, 


5 


SAY 


3 


17, 


8 


GET 


3 


17, 


15 


SAY 


3 


17, 


44 


GET 


3 


17, 


51 


SAY 


3 


18, 


5 


SAY 


3 


18, 


8 


GET 


3 


18' 


15 


SAY 


2 


18, 


44 


GET 


3 


18, 


51 


SAY 


3 


13, 


5 


SAY 


2 


19, 


8 


GET 



"CONTRACTOR DISCIPLINE PROFILE" 
"Contractor Number -" 
cnum 1 

"Contractor Name -" 
enamel 

"Discipline Code - Number of Personnel" 
"0 1 " 



mnad 

"Administrative 

mnee 

"Electrical Eng" 

"03" 

mnog 

"Oceanograhers 

mna 

"Architect" 

" 05 " 
mn est 

"Estimators 

mnup 

"Urban Planners" 

"07" 

mnche 

"Chemical Eng 
mnge 

"Geologists" 

"09" 

mnsne 

"Sanitary Eng 
mnee 

"Civil Eng" 

" 11 " 

mnhv 

"Hydrologists 

mnsoe 

"Soils Eng" 

"13" 

mnei 

"Construct Insptr 
mnid 

"Interior Designer" 

"15" 

mnsp w 

"Spec Nriter 
mnamn 

"Draftsman" 

"17" 

mnla 

"Landscape Arch 
mnst e 

"Structural Eng" 

"19" 

mneco 

"Ecologists 

mnme 

"Mechanical Eng" 

" 21 " 

mnsur 

"Surveyors 

mnecn 

"Economists" 

" 23 " 

mnrane 



02 " 



04" 



0 6 " 



08" 



10 " 



12 " 



14 " 



16 " 



18" 



20 " 



22" 
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a> e; p> a> 



24" 



19, 15 

19,44 
19, 51 

20, 5 
20 , 5 
20,15 
22 , 0 
22,55 



SAY "Mining Eng 
GET mntre 

SAY "Transport Eng" 

SAY "25" 

GET mnge 
SAY "General" 

SAY " > DO YOU WANT TO INPUT ANOTHER RECORD? ( 

GET answer 



Y or N ) " 
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refe(ere(Bfer6re(ererere<ere<ecers(erererefere>re(6re(ere(e 



Saycdata Screen Format 



* SAYCDATA. FMT 6/5/84 jte 

5) 1, 0 SAY " 



2 

4 

4 

4 

4 

6 

6 

7 

7 

9 

9 

1 1 
1 1 
1 1 
1 1 
1 1 
1 1 

13 

14 

14 

15 

15 

16 
16 
17 

17 

18 
18 
19 
19 
21 
21 



21 

0 

20 

38 

46 
0 

18 

16 

18 

0 

20 

0 

7 

36 

44 

52 

58 

10 

0 

12 

0 

e 

o 

12 

0 

6 

0 

12 

0 

6 

0 

47 



SAY "CONTRACTOR DATA FILE" 

SAY "Contractor Number -" 

SAY cnuml 
SAY "Phone -" 

SAY phone 

SAY "Contractor Name -" 

SAY enamel 

S^y ii_n 

SAY cname2 

SAY "Street cr P.O.Box -" 

SAY stpob 
SAY "City -" 

SAY city 
SAY "State 
SAY state 
SAY "Zip -" 

SAY zip 

SAY " PROJECT HISTORY " 

SAY "Project 1 -" 

SAY projl 
SAY "Fee 
SAY feel 

SAY "Project 2 -" 

SAY proj2 
SAY *Fee 
SAY fee2 

SAY "Project 3 -" 

SAY pro j 3 
SAY "Fee -" 

SAY fee3 

SAY " > IS THIS THE RECORD YOU WANT? ( Y or N ) " 

GET answer2 
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Saycdis Screen Format 






SAYCDIS. FMT 6/5/84 jte 

^ A C 71 V 11 


1 t 




~ it 1 


ft 




2 


18 


SAY 


"CONTRACTOR DISCIPLINE PROFILE 1 ' 


4 


0 


SAY 


"Contractor Number 




4 


20 


SAY 


cnum 1 




5 


0 


SAY 


"Contractor Name 




5 


18 


SAY 


enamel 




7 


0 


SAY 


"Discipline Code - Number 


of Personnel" 


8 


5 


SAY 


"0 1" 




8 


8 


SAY 


nad 




8 


14 


SAY 


"Administrative 


02" 


8 


43 


SAY 


nee 




8 


49 


SAY 


"Electrical Eng" 




9 


5 


SAY 


"03" 




9 


8 


SAY 


nog 




9 


14 


SAY 


"Oceanograhers 


04" 


9 


43 


SAY 


na 




9 


49 


SAY 


"Architect" 




10 


5 


SAY 


"05" 




10 


8 


SAY 


nest 




10 


14 


SAY 


"Estimators 


06" 


10 


43 


SAY 


nup 




10 


49 


SAY 


"Urban Planners" 




1 1 


5 


SAY 


"07" 




1 1 


8 


SAY 


nche 




1 1 


14 


SAY 


"Chemical Eng 


08" 


1 1 


43 


SAY 


nge 




1 1 


49 


SAY 


"Geologists" 




1 2 


5 


SAY 


"09" 




12 


8 


SAY 


nsne 




1 2 


14 


SAY 


"Sanitary Eng 


10" 


12 


43 


SAY 


nee 




12 


49 


SAY 


"Civil Eng" 




13 


5 


SAY 


"11" 




13 


8 


SAY 


nhy 




13 


14 


SAY 


"Hydrologists 


12" 


13 


43 


SAY 


nsoe 




13 


49 


SAY 


"Soils Eng" 




14 


5 


SAY 


"13" 




1 4 


8 


SAY 


nci 




14 


14 


SAY 


"Construct Insptr 


14" 


1 4 


43 


SAY 


nid 




14 


49 


SAY 


"Interior Designer" 




15 


5 


SAY 


"15" 




1 5 


8 


SAY 


nspw 




15 


14 


SAY 


"Spec Writer 


16" 


15 


43 


SAY 


ndmn 




1 5 


49 


SAY 


"Draftsman" 




16 


5 


SAY 


"17" 




16 


8 


SAY 


nla 




16 


14 


SAY 


"Landscape Arch 


18" 


16 


43 


SAY 


nste 




16 


49 


SAY 


"Structural Eng" 




17 


5 


SAY 


"19" 




1 7 


8 


SAY 


neco 




17 


14 


SAY 


"Ecologists 


20" 


17 


43 


SAY 


nme 




17 


49 


SAY 


"Mechanical Eng" 




18 


5 


SAY 


"21" 




18 


8 


SAY 


nsur 




18 


14 


SAY 


"Surveyors 


22" 


18 


43 


SAY 


necn 




18 


49 


SAY 


"Economists" 




19 


5 


SAY 


"2 3" 




1 9 


8 


SAY 


nmne 





* * 
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19, 

19, 

19, 

20 , 
20 , 
20 , 
21 , 
22 , 



3 
3 
3 
3 
3 
3 
3 
3 

3 22,52 



14 

43 

49 

5 

£ 

14 

0 

0 



SAY "Mining Eng 24" 

SAY ntre 

SAY "Transport Eng" 

SAY "25" 

SAY nge 

SAY "General" 

SAY "Choose cne of the following options:" 
SAY "B) ackward, D)ata file, F)orward, H) elp , 
GET answer 



or Q) ait" 



118 






Viewdata Screen Format 
* VCDATA. FMT 6/5/84 jte 

3) 1/0 SAY " 



2 

4 

4 

4 

4 

6 

6 

7 

7 

9 

9 

1 1 
1 1 
1 1 
1 1 
11 
1 1 

13 
1 4 

14 

15 

15 

16 
16 

17 
1 7 

18 
18 
19 

19 

20 

21 

21 



21 

0 

20 

38 

46 

0 

18 

16 

18 

0 

20 

0 

7 

36 

44 

52 

58 

10 

0 

12 

0 

6 

0 

12 

0 

6 

0 

12 

0 

6 

0 

1 

54 



SAY "CONTRACTOR DATA FILE" 

SAY "Contractor Number -" 

SAY cnuml 
SAY "Phone -" 

SAY phone 

SAY "Contractor Name -" 

SAY enamel 
SAY " 

SAY cname2 

SAY "Street or P.O.Box -" 

SAY stpob 
SAY "City -" 

SAY city 
SAY "State 
SAY state 
SAY "Zip 
SAY zip 

SAY " PROJECT HISTORY " 

SAY "Project 1 -" 

SAY projl 
SAY "Fee 
SAY feel 

SAY "Project 2 -" 

SAY proj2 
SAY "Fee -" 

SAY fee2 

SAY "Project 3 -" 

SAY pro jJ 
SAY "Fee -" 

SAY fee3 

SAY " 

•• 

SAY "B) ack F) orward P) rofile N) umber Q) uit" 
GET vcommand 



* $♦***#* 
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Viewcdis Screen Format 

************** **************** ************ ********* **** *********** 
VCDIS.FMT 6/5 /84 jte 

3 0, 0 SAY " 

n 



1 

3 

3 

4 
4 
6 
7 
7 
7 
7 

7 

8 
8 
8 
8 
8 
9 
9 
9 
9 
9 

10 
10 
10 
10 
10 
1 1 
1 1 
11 
1 1 
1 1 
12 
12 
12 
12 
12 
13 
13 
13 
13 

13 

14 
14 
14 
14 

14 

15 
15 
15 
15 

15 

16 
16 
16 
16 
16 

a 17 
3 17 
3 17 
3 17 
3 17 
a 18 
a 18 
a 18 



18 SAY 
0 SAY 
20- SAY 
0 SAY 
18 SAY 
0 SAY 



5 

8 



DISCIPLINE 
Number -" 

Name -" 



SAY 
. SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 
43 SAY 
49 SAY 
5 SAY 
8 SAY 
14 SAY 



"CONTRACTOR DISCIPLINE PROFILE" 
"Contrac ter 
cnum2 

"Contractor 
name 

"Discipline Code - Number 
" 01 " 
nad 

"Administrative 
nee 

"Electrical Eng" 

"03" 
nog 

"Oceanograhers 
na 

"Architect" 

"0 5" 
nest 

"Estimators 
nup 

"Urban Planners" 

"07" 
nche 

"Chemical Eng 
nge 

"Geologists" 

"09" 
nsne 

"Sanitarv Eng 
nee 

"Civil Eng" 

"11" 
nhy 

"Hydrologists 
nsoe 

"Soils Eng" 

"13" 
nci 

"Construct Insptr 
nid 

"Interior Designer" 

"15" 
nspv 

"Spec Writer 
ndran 

"Draftsman" 

" 17 " 
nla 

"Landscape Arch 
nste 

"Structural Eng" 

n -j g ii J 

neco 

"Ecologists 
nme 

"Mechanical Eng" 

" 21 " 
nsur 

"Surveyors 
necn 

"Economists" 

"2 3" 
nmne 

"Mining Eng 



of Personnel" 



02 " 



04" 



06" 



08" 



10 " 



12" 



14" 



16" 



18" 



20 " 



22 " 



24 " 
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18,43 SAY ntre 
18,49 SAY "Transport Eng" 

19, 5 SAY "25" 

19, 8 SAY nge 

19, 14 SAY "General" 

20, 0 SAY " 

n 

3 21, 0 SAY " >Fress any key to continue 
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APPENDIX B 



A-E MANAGEMENT INFORMATION SYSTEM COMPONENTS 

Below is a listing of the components which makeup the 
A-E Management Information System. The listing is broken 
into four categories: databases, files, repor ts/ietters 
file, and applications. 



Dat abases 

Phases ISII Tracking Contract Specialist 

labor Costs Contractor Information 

Board Members System 

Provisions Phase III Tracking 

Drawing Numbers Modifications Tracking 

Payments 



Applications 



Phase ISII Tracking 
Contract Assignment 
Clearances/Approvals I 
Cert if icat es/Apprcvals 
II/III 

Evaluation Calculator 

Signature 

DD 1057 

Progress Payment 



Phase III Tracking 
Estimates 

Contractor Information 
System 

Board Selections 
Estimate Evaluator 
DD 350 
DD 1413 



Files 

Contracts 



Reports/ Letters 



Customer Notification 

Clearances/Approvals 

CBD 

Pre-Selection Board 
Report 

Interviewers Instructions 
Selection Board Report 
Negotiation Board Report 
Contractor Notification 
letter 

Contractor Meeting 
Checklist 

Contractor Release 



Cost Estimate 

Workshee t 

3oard Appointments 
Interview Letter 
Interview Evaluation 
Sheet 
G.E. Form 
DD 350 
DD 1057 
DO 1413 
Design Review 

Documents 



123 



LIST OF REFERENCES 



1. Naval Facilities Engineering Command, Washington, 

D.C. , P-424, Navy Facilities System Plan, October 

2. Naval Facilities Engineering Command, Washington, 

D.C., P-68, Contr act ing Manual, Section 1, Part 3; 

January 1979. 

3. Naval Material Command, Washington, D.C., P-4202, Navy 
Co ntr acti ng Direc tive s (NCD/NPD) , Sections 1-40T753 
and 7-601. 2. 

4. Senn, J. A., I nfo rma tion Sy stems in Man agement, 2nd 
ed., p. 335, WadsworEE, Inc., T9 W2. 

5. Facilities Systems Office Publication No. HXX00G00, 
Engineering Fiel d Division M anagem e nt Sy stem : 
Execu tiv e Over view , Port Hueneme, la . 7 July 1981. 

6. Facilities Systems Office Publication No. H2500H00, 
Contractor Information System: User M anua l Revision 4, 
Ford Hueneme, Ca. , Ipril T9HT. 

7. Nolan, R. A., '’Managing the Crisis in DP", Harvard 

Business Review, vol. 57, No. 2, pp. 115-126 , Har/Tpr 
T9797 



8 . 



Aron, J.D., "Information Systems in Perspective", 
Compu tin g Surveys , vol. 1, No. 4, pp. 213-936, Dec. 
T969 . 



9. Larson, J.A., Tutorial: End U ser Faci li ties in the 

1 9 80 ’ s, IEEE Computer EocieEy Press, T9H1. 

10. Peterson, D.E., "Screen Design Guidelines", Small 
Systems World , vol. 6, No. 8, February 1979. 



11 



NAVFAC Instruction 5236. 2B, 15 August 1983. 



124 



INITIAL DISTRIBUTION LIST 



No. Copies 



1. Defense Technical Information Center 2 

Cameron Station 

Alexandria, VA 22214 

2. Litrarv, Code 0142 2 

Naval Postgraduate School 

Mcnterey, CA 93943 

3. Computer Technology Programs, Code 37 1 

Naval Postgraduate School 

Mcnterey, CA 93943 

4. LCDR W. Talutis, Code 54TA 1 

Administrative Sciences Department 

Naval Postgraduate School 
Mcnterey, CA 93943 

5. Prof N. Lyons, Code 54LB 1 

Administrative Sciences Department 

Naval Postgraduate School 
Mcnterey, CA 93943 

6. LCDR R. E. Etheridge 1 

Eranch Dental Clinic 

N AVSUP ACT Holy Loch 
FPO New York 09514 

7. Naval Facilities Engineering Command 1 

Code 011 

200 Stovall Street 
Alexandria, VA 22332 

8. Naval Facilities Engineering Command 1 

Code 04 

200 Stovall Street 
Alexandria, VA 22332 

9. LCDR. J. T. Etheridge 2 

CBC Code18 A FACSC 

Port Hueneme, Ca. 93043 



125 



210176 



Thesis 

E7126 

C.l 



Thesis 
E7126 
c .1 



Etheridge 

Automation of the re- 
porting and tracking 
requirements of Archi- 
tect-Engineering type 
contracts • 



r'-y 

t- 



. 1/176 



Etheridge 

Automation of the re- 
porting and tracking 
requirements of Archi- 
tect-Engineering type 
contracts . 



